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

[Jakub Kicinski <kuba@kernel.org>]

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.