Re: [PATCH net-next v2 1/6] net/tls: Bound consecutive no-data records in tls_sw_read_sock()

On Tue, Jul 28, 2026, at 9:47 PM, Jakub Kicinski wrote:

On Mon, 20 Jul 2026 10:27:55 -0400 Chuck Lever wrote:

quoted

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.

Is this alluding to PREEMPT_NONE (which for practical purposes is 
no longer a thing AFAIU)?

No. The cond_resched() reference was a bad way to make the point.

What the bound protects is the calling NFSD thread. A client can
open multiple connections that all send a continuous stream of empty
TLS records, as a denial of service attack. The mechanism added
here is an escape hatch for consumers.

This patch has already moved to a prerequisite series, intended for
“net” instead of “net-next” at Sabrina’s request.

https://lore.kernel.org/r/20260726-tls-follow-on-v1-0-99bf4cc1c729@kernel.org (local)

-- 
Chuck Lever