Re: [PATCH] net/ceph/messenger: print TCP connect error

[Xiubo Li]

On Tue, Nov 3, 2026 at 8:06 AM Max Kellermann <max.kellermann@xxxxxxxxx> wrote:
> On Mon, Nov 2, 2026 at 10:08 PM Ilya Dryomov <idryomov@xxxxxxxxx> wrote:
> > I wonder if saving the error that way is actually needed.  Can
> > con_fault() just reap it with sock_error() at the time it runs?
>
> Maybe that would be possible.  I wasn't sure if sk_err (from
> ceph_sock_state_change()) would remain untouched until con_fault() was
> eventually called, or if it somebody would clear it in the meantime.

It does get cleared, by ceph_con_workfn() itself.  SOCK_CLOSED is only
checked at the top of the loop, so if the error arrives after that
check, the ceph_tcp_sendmsg()/recvmsg() in the same pass reaps sk_err
via sock_error() and con_fault() later sees 0.

I tried both on a 7.3-rc1 kernel.  Reaping in con_fault() works for the
remote ECONNREFUSED and ECONNRESET cases, but with a refused connect on
loopback (ms_mode=legacy and crc) the error was lost every time:

  state_change sk_state 7 sk_err 111
  try_write ret -111, sk_err 0
  con_fault: sock_error() = 0
  libceph: mon0 (1)127.0.0.1:1 socket error on write

With this patch the same case prints "socket error on write
(-ECONNREFUSED)".  Using the try_read/try_write return value instead
doesn't work well either, because msgr1 returns -1 for protocol
errors.  So saving the error in ceph_sock_state_change() looks like the
simpler option to me.

A normal FIN-close prints no error code, and a synchronous connect
failure prints "connect error (-ENETUNREACH)".

Nit: msgr2 still prints "ceph_tcp_connect failed: %d" in
prepare_read_banner_prefix()'s caller, which is now redundant.

Reviewed-by: Xiubo Li <xiubo.li@xxxxxxxxx>

Thanks
- Xiubo

Max Kellermann <max.kellermann@xxxxxxxxx> 于2026年11月3日周二 08:06写道：
>
> On Mon, Nov 2, 2026 at 10:08 PM Ilya Dryomov <idryomov@xxxxxxxxx> wrote:
> > I wonder if saving the error that way is actually needed.  Can
> > con_fault() just reap it with sock_error() at the time it runs?
>
> Maybe that would be possible.  I wasn't sure if sk_err (from
> ceph_sock_state_change()) would remain untouched until con_fault() was
> eventually called, or if it somebody would clear it in the meantime.
>
> --
> Max Kellermann
> Principal Architect
> Hosting Technology
>
> cm4all | Im Mediapark 6a | 50670 Köln | Germany
> General information about the company can be found here:
> https://www.cm4all.com/impressum
> A member of the IONOS Group
>