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

[Jakub Kicinski <kuba@kernel.org>]

On Thu, 30 Jul 2026 16:16:33 +0200 Sabrina Dubroca wrote:
> 2026-07-29, 16:31:42 -0700, Jakub Kicinski wrote:
> > On Tue, 28 Jul 2026 22:51:30 -0400 Chuck Lever wrote:  
> > > 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 ;/