Thread (36 messages) 36 messages, 4 authors, 2026-07-31

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

flat view

From: Jakub Kicinski <kuba@kernel.org>
Date: 2026-07-29 01:55:27
Also in: linux-kselftest, linux-nfs

On Tue, 28 Jul 2026 21:46:57 -0400 Chuck Lever wrote:
On Tue, Jul 28, 2026, at 9:43 PM, Jakub Kicinski wrote:
quoted
On Mon, 20 Jul 2026 10:27:54 -0400 Chuck Lever wrote:  
quoted
- 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?
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help