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

[Sabrina Dubroca <sd@queasysnail.net>]

2026-07-30, 14:35:56 -0700, Jakub Kicinski wrote:
> 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 ;/

I think "if you do recvmsg with a cmsg and pages, your control records
end up in the pages".

To avoid that, you'd have to run recvmsg-nocmsg/read_sock to get all
the DATA out, then once you know the next chunk of payload is a
control record (and hopefully nothing else is reading from your
socket), one recvmsg+cmsg into a separate buffer.

The weird read_sock_rectype magic here avoids all that.

-- 
Sabrina