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?
