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

[Jakub Kicinski <kuba@kernel.org>]

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?

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