Re: [PATCH net-next v2 2/6] net: Introduce read_sock_rectype proto_ops for control record delivery

On Thu, 30 Jul 2026 16:16:33 +0200 Sabrina Dubroca wrote:

2026-07-29, 16:31:42 -0700, Jakub Kicinski wrote:

quoted

On Tue, 28 Jul 2026 22:51:30 -0400 Chuck Lever wrote:  

quoted

No-one is asking you to roll over. Review means you get to steer
us in the right direction, and I promise to do the leg work. Terse
rejection doesn’t move the discussion forward. It stops it cold.  

With LLMs tho, the entire human effort is in finding the right design,
rather than the code. So asking maintainers to hand hold everyone thru
their features is unrealistic.

Off the top of my head I think a setsockopt which pre-seeds the content
type so that the read returns an errno if the queued content type is
different could be a simple fix. You'd configure that on your sockets
to DATA and once you see a EWHATEVER you'd assume that some special
record arrived and the socket has to be handed back over to the TLS
control path. This is literally the first thing that comes to mind,
IDK how ugly it will look in reality so no promises.  

But then you're back to "read_sock stopped, caller has to take some
special action to handle the next bit of payload". It's not better
than "read_sock, and do a recvmsg when read_sock says it's not DATA".

My bad, I replied without looking at the code.
We already constrain control records in the way I proposed.
rcvmsg (w/o cmsg) and read_sock will error out if the next
record is control.

I guess I don't understand what Chuck meant when he said that
he has control data leaking into page cache ;/