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

On Tue, Jul 28, 2026, at 10:30 PM, Jakub Kicinski wrote:
> On Tue, 28 Jul 2026 21:57:21 -0400 Chuck Lever wrote:
>> > To me this is an ugly one-off workaround that doesn't fit into=20
>> > the proto_ops (only TLS will use it). And you seem to net out
>> > to the same LOC on SUNRPC side with and without this? =20
>>=20
>> It=E2=80=99s not about LOC. It=E2=80=99s about not cluttering the nor=
mal 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=E2=80=99s 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=E2=80=99t move the discussion forward. It stops it cold.

Complaining about slop also does not tell me where you need this
to go. I use AI to go from blank page to RFC/v1. Where we go next
is up to human taste, as always.


>> > There needs to be a very strong reason for us to add APIs for
>> > in kernel consumers. =20
>>=20
>> This is not a helpful position. Your objection is the same
>> every time, treating the in-kernel users as second-class
>> citizens.
>
> No, it's not a second class citizen. But kernel consumers have a
> tendency to break all abstractions and insert hacks all over the place
> just because they are not forced to go via uAPI boundary which forces
> people to think about the API design.

Granted that user space self-tests can=E2=80=99t reach kernel-only APIs.
But that is what Kunit is for.


> You just need to try a little harder to produce a better solution.
> Rework or augment existing callbacks to let your achieve the behavior
> you want.

My original approach was to add a new read_sock variant because I
suspected you wouldn=E2=80=99t want read_sock itself to grow another arg=
ument.

I thought the RFC series cover letter made it clear that we are
looking for input and direction, not to sell a completely formed idea.


--=20
Chuck Lever