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

[Maximilian Immanuel Brandtner]

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 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.