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

[Maximilian Immanuel Brandtner <maxbr@linux.ibm.com>]

On Fri, 2026-07-24 at 09:40 +0200, Paolo Abeni wrote:
> On 7/23/26 6:26 PM, Jakub Kicinski wrote:
> > On Mon, 20 Jul 2026 11:08:47 +0200 Maximilian Immanuel Brandtner
> > wrote:
> > > 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.