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

On Thu, Jul 30, 2026, at 5:35 PM, 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:

>> > Off the top of my head I think a setsockopt which pre-seeds the con=
tent
>> > 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 socke=
ts
>> > 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. =20
>>=20
>> 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".

But the =E2=80=9Crecover the control type with a separate operation=E2=80=
=9D is strictly
better than =E2=80=9Cpass a CMSG buffer to every I/O operation just in c=
ase=E2=80=9D ;-)


> 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.

Almost.

There is no API contract for ->read_sock, but the TLS read_sock
implementation itself will return -EINVAL for two unrelated reasons:

  - net/tls/tls_sw.c:2068-2072 =E2=80=94 entry gate: sk_psock_get(sk) re=
turns
    non-NULL, so the socket is under sockmap/BPF. Drop the ref and
    refuse before even acquiring the reader.

  - net/tls/tls_sw.c:2111-2115 =E2=80=94 per-record: tlm->control !=3D
    TLS_RECORD_TYPE_DATA. The record is requeued rather than consumed.

As far as I can tell, no other socket provider that implements read_sock
will return -EINVAL. But this isn=E2=80=99t a documented guarantee that a
socket consumer can depend on, currently.

What would make this just a little friendlier is having distinct errnos
for these two conditions, and a kdoc API contract that documents them.


--=20
Chuck Lever