On Tue, Oct 13, 2026, [email protected] wrote: > > [Severity: Medium] > The socket lock is held across the retry. If the peer keeps sending empty > records, how long can this loop keep lock_sock() ownership and the TLS > reader lock?
For as long as a record is already parsed, the same as the loop in tls_sw_recvmsg(). Once the receive queue drains, tls_rx_rec_wait() flushes the backlog and then sleeps or returns -EAGAIN, so each drain cycle gives up the CPU. The cover letter explains why only tls_sw_read_sock() takes a count: its callers hold the socket lock across the call and never return to user space. A splice() caller runs in its own process context and holds only its own socket. > [Severity: Medium] > Can this retry make SO_RCVTIMEO restart with every empty record? Yes. The cover letter states that SO_RCVTIMEO does not bound these calls. recvmsg() behaves this way today. splice() now matches that behavior. A nonblocking splice() that finds no record ready returns -EAGAIN from tls_rx_rec_wait(), so a flood holds the caller only while records are already parsed. -- Chuck Lever (Come to NFS bake-a-thon! https://nfsv4bat.org)
