On Mon, Oct 05, 2026, [email protected] wrote:
> > err = tls_rx_rec_wait(sk, flags & SPLICE_F_NONBLOCK,
> > - true, false);
> > + released, false);
>
> [Severity: Medium]
> With the new goto retry below, can this wait now block on a socket that
> has O_NONBLOCK set?
Yes, between this patch and 4/8. Before this patch, a caller that
polled and then spliced found a record ready and never reached the
sleep. With the retry, an empty record followed by nothing sleeps
in tls_rx_rec_wait() unless SPLICE_F_NONBLOCK is set.
In v3 the O_NONBLOCK patch will be ordered ahead of this one.
> > + if (signal_pending(current)) {
> > + long timeo;
> > +
> > + timeo = sock_rcvtimeo(sk, flags & SPLICE_F_NONBLOCK);
> > + err = sock_intr_errno(timeo);
> > + goto splice_read_end;
> > + }
> > + goto retry;
>
> [Severity: Medium]
> How many consecutive empty records can this loop consume while it holds
> the socket lock?
As many as the peer sends back to back. I don't plan to cap it.
The limit in 1/8 works because a read_sock consumer takes a zero
return with nothing copied as "no progress". A splice read has no
such return. Zero means EOF, which is the bug this patch fixes, and
a blocking caller cannot be handed -EAGAIN. The retry is what
tls_sw_recvmsg() already does with an empty record.
The loop runs in the caller's own syscall and the signal test
keeps the task killable. It ends when the peer stops sealing
records faster than the reader opens them. Other tasks that
call lock_sock() on the same socket do wait for that.
--
Chuck Lever (Come to NFS bake-a-thon! https://nfsv4bat.org)
