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 somee
proof
that it's needed.

/P

Also you may just have forgotten to mention it, but EINTR can also be
returned from sock_intr_errno(), so at the very least the error codes
EAGAIN, EINTR, ERESTARTSYS should be treated as non-fatal.