Re: [PATCH net-next v2 1/6] net/tls: Bound consecutive no-data records in tls_sw_read_sock()
Hannes Reinecke <[email protected]> Thu, 23 Jul 2026 09:11:03 +0200
| Newsgroups | dev.linux.lists.kernel-tls-handshake,org.kernel.vger.linux-kselftest,org.kernel.vger.linux-nfs,org.kernel.vger.netdev |
|---|---|
| Message-ID | <[email protected]> |
On 7/20/26 4:27 PM, Chuck Lever wrote: > A record that delivers no payload -- an empty TLS 1.3 data record > today, a control record once read_sock_rectype() lands -- leaves > tls_sw_read_sock() in its loop without advancing the caller's read > descriptor. A peer that streams such records keeps the receive loop > running, and the socket lock held, for as long as the records > arrive. > > Cap the number of consecutive no-data records consumed per call. The > count resets on any record that delivers bytes, so a normal stream > is unaffected; a peer supplying only empty records is bounded to > TLS_RX_NODATA_LIMIT iterations before the call returns 0. read_sock > consumers treat that as "no progress, re-poll" rather than EOF, so > the connection stays up and makes progress once real data arrives. > > Only tls_sw_read_sock() needs this cap. Its consumers drive the receive > loop from kernel context -- a work item or service thread holding the > socket lock across the whole call with no return to userspace -- so an > unbounded empty-record stream keeps that context and the lock pinned > for as long as the flood lasts. The cap supplies the return boundary > that a system call would otherwise provide. tls_sw_splice_read() > and tls_sw_recvmsg() already have one: they run in the calling task's > context, reschedule while draining the socket backlog (cond_resched() > in __release_sock()), and drop the socket lock when the call returns. A > flood there costs the caller only its own scheduler time, so the cap > would add nothing. > > Signed-off-by: Chuck Lever <[email protected]> > --- > net/tls/tls_sw.c | 13 +++++++++++++ > 1 file changed, 13 insertions(+) > This is technically a fix, so it might be worthwhile sending it on its own. Otherwise: Reviewed-by: Hannes Reinecke <[email protected]> Cheers, Hannes -- Dr. Hannes Reinecke Kernel Storage Architect [email protected] +49 911 74053 688 SUSE Software Solutions GmbH, Frankenstr. 146, 90461 Nürnberg HRB 36809 (AG Nürnberg), GF: I. Totev, A. McDonald, W. Knoblich