Re: [PATCH] tls: don't abort the connection on signal-interrupted sends

On Fri, 2026-07-24 at 09:40 +0200, Paolo Abeni wrote:

On 7/23/26 6:26 PM, Jakub Kicinski wrote:

quoted

On Mon, 20 Jul 2026 11:08:47 +0200 Maximilian Immanuel Brandtner
wrote:

quoted

When a signal interrupts a blocking send, tls_tx_records() treats
the
resulting -ERESTARTSYS as a transmission failure and marks the
socket
errored via tls_err_abort() with the raw error code. Later
syscalls
return the kernel-internal errno 512 (ERESTARTSYS) to userspace,
as the
signal it stems from is no longer pending during syscall exit and
thus
never translated.

Can we just add ERESTARTSYS handling? I never heard of the other
codes
you're checking TBH, can they actually surface?

FTR, I think only EAGAIN and ERESTARTSYS can be observed in the
network
stack, and the latter only after sock_intr_errno() translation, i.e.
on
sendmsg()/recvmsg() return path.

I would not add additional error code handling, until we have some
proof
that it's needed.

/P

Is this an explicit requirement in the subsystem or just a practical
observation. Because if this is only fixed for ERESTARTSYS and some
part of the networking subsystem later introduces code that might
return these other restart error codes the same problem could occur
again. By my lights, it's better to err on the side of caution, but if
we can be certain that this assumption won't be broken in the future
I'd be fine with dropping the other restart error codes.