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