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

["Chuck Lever" <cel@kernel.org>]

On Tue, Jul 28, 2026, at 9:55 PM, Jakub Kicinski wrote:
> 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?

I did not write this text. It was written with Opus 5 and reviewed by
gpt-5.6, sashiko (gemini), and myself, repeatedly.

I’m not aware of a requirement to add an AI-related tag to a series
cover letter, nor am I aware of any a priori prohibition against
using assistance when composing one.

I agree it needlessly duplicates content from the patch commit messages.
It is bland, but I don’t find it nonsensical, or I wouldn’t have posted
it for review.


-- 
Chuck Lever