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

["Chuck Lever" <cel@kernel.org>]

On Tue, Jul 28, 2026, at 9:51 PM, Jakub Kicinski wrote:
> On Mon, 20 Jul 2026 10:27:56 -0400 Chuck Lever wrote:
>> Kernel TCP consumers that use the read_sock interface
>> (proto_ops.read_sock) cannot receive TLS control messages (Alerts,
>> Handshake records) when kTLS is active. The current
>> tls_sw_read_sock() method rejects non-data records with -EINVAL, and
>> the sk_read_actor_t callback has no channel for delivering record-
>> type metadata.
>> 
>> Four kernel subsystems are affected: NFSD (sunrpc svcsock), NFS
>> client (sunrpc xprtsock), NVMe target (nvmet-tcp), and NVMe host
>> (nvme-tcp). Each of these either falls back to the sock_recvmsg()
>> API or lacks TLS alert handling entirely.
>> 
>> A new read_sock_rectype method in struct proto_ops provides a
>> separate code path that delivers non-data TLS records to a callback,
>> without changing the behavior seen by existing read_sock consumers.
>> 
>> The new sk_read_rectype_actor_t callback type extends the
>> sk_read_actor_t signature with a rectype parameter carrying the
>> protocol-layer record type (for example, TLS_RECORD_TYPE_ALERT). The
>> record-type callback returns 0 to consume a record or a negative
>> value to requeue it and stop delivery; unlike the data callback, its
>> return value does not count bytes.
>
> To me this is an ugly one-off workaround that doesn't fit into 
> 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?

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.


> There needs to be a very strong reason for us to add APIs for
> in kernel consumers.

This is not a helpful position. Your objection is the same
every time, treating the in-kernel users as second-class
citizens. You haven’t provided a single alternative to address
our concerns, and you have not explained why an additional API
is a problem.

Please put down your hostility and elaborate. You seem to be
the only one who has a problem with any of this.

-- 
Chuck Lever