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

2026-07-29, 16:31:42 -0700, Jakub Kicinski wrote:
> On Tue, 28 Jul 2026 22:51:30 -0400 Chuck Lever wrote:
> > >> It’s not about LOC. It’s about not cluttering the normal I/O
> > >> path with a lot of exception processing to handle TLS Alert
> > >> records. The CMSG API is very difficult to use and leaks the
> > >> alert messages into I/O buffers (which for in-kernel consumers
> > >> are page cache pages). It’s piss-poor API design.  
> > >
> > > I'm not arguing that it's amazing. Doesn't mean we will YOLO
> > > a special proto callback for every protocol stacking :/  
> > 
> > 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".

-- 
Sabrina