Re: [PATCH net-next v2 0/6] Deliver TLS control records to kernel read_sock consumers

Jakub Kicinski <[email protected]> Tue, 28 Jul 2026 18:55:25 -0700
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 Tue, 28 Jul 2026 21:46:57 -0400 Chuck Lever wrote:
> On Tue, Jul 28, 2026, at 9:43 PM, Jakub Kicinski wrote:
> > On Mon, 20 Jul 2026 10:27:54 -0400 Chuck Lever wrote:  
> >> - The no-data cap (patch 1) is a prerequisite, not a stand-alone fix.
> >>   Once control records reach read_sock, a record carrying no payload
> >>   stops advancing the caller's read descriptor, so a peer streaming
> >>   such records would pin the socket lock and the kernel receive
> >>   context for as long as the flood lasts. Bounding consecutive
> >>   no-data records supplies the return boundary a system call would
> >>   otherwise provide. The cap is scoped to tls_sw_read_sock() alone:
> >>   splice and recvmsg run in the caller's own context, reschedule, and
> >>   drop the lock on return, so they need nothing.  
> >
> > Is it just me or this is incomprehensible slop? Run on sentences 
> > full of terms no kernel developer would use?  
> 
> It makes sense to me. Which terms do you have trouble with?
> 
> Patch 1 is moving to a pre-requisite series, so this can be dropped
> from the cover letter.

Did you write this? If not what model did you use?