Re: [PATCH net-next v2 0/6] Deliver TLS control records to kernel read_sock consumers

On 7/20/26 4:27 PM, Chuck Lever wrote:

When kTLS is active, kernel consumers of the read_sock API cannot
see TLS control records: tls_sw_read_sock() rejects Alerts and
Handshake records with -EINVAL. A consumer that needs those records
falls back to sock_recvmsg() with ancillary buffers, which is why
NFSD's svcsock runs a MSG_CTRUNC recovery dance on every receive.

This series adds a read_sock_rectype proto_ops method that delivers
non-data records through a separate callback, then converts its first
consumer, NFSD's svcsock, to use it. NFS client (xprtsock), NVMe
target, and NVMe host are meant to move onto the same mechanism in
later series. The existing read_sock data path is unchanged.

The improvement is more than cosmetic. All of these consumers need
to handle TLS Alert messages efficiently and securely (in particular,
for KeyUpdate). A few design points worth mentioning:

- The new sk_read_rectype_actor_t callback does not share the data
   actor's byte-counting contract. It returns 0 to consume a record or
   a negative value to requeue it and stop delivery. The return is
   never a byte count. svc_tcp_rectype_actor() relies on this,
   returning 0 to consume every non-data record while stopping the
   read loop through desc->count on a fatal alert.

- The no-data cap (patch 1) is a prerequisite, not a stand-alone fix.
   Once control records reach read_sock, a record carrying no payload
   stops advancing the caller's read descriptor, so a peer streaming
   such records would pin the socket lock and the kernel receive
   context for as long as the flood lasts. Bounding consecutive
   no-data records supplies the return boundary a system call would
   otherwise provide. The cap is scoped to tls_sw_read_sock() alone:
   splice and recvmsg run in the caller's own context, reschedule, and
   drop the lock on return, so they need nothing.

- The svcsock conversion is split so the new path can be reviewed
   against the old. The old path is then removed by the last patch
   in the series.

- read_sock_rectype has no direct userspace entry point, so its
   selftest coverage (patch 4) drives the shared decryption and
   rx_list delivery pipeline through the recvmsg and splice paths
   instead.

---
Changes in v2:
- Renamed the read_sock_cmsg proto_ops method to read_sock_rectype.
- Non-data records now use a record-type actor, not RFC cmsg-style.
- Bound no-data records so they can't pin the socket lock (new patch 1).
- Added selftests for data/control record interleaving (new patch 4).
- Link to v1: https://lore.kernel.org/r/20260217222033.1929211-1-cel@kernel.org

---
Chuck Lever (6):
       net/tls: Bound consecutive no-data records in tls_sw_read_sock()
       net: Introduce read_sock_rectype proto_ops for control record delivery
       tls: Implement read_sock_rectype for kTLS software path
       selftests/tls: Add tests for data/control record interleaving
       SUNRPC: Use read_sock_rectype for svcsock TCP receives
       SUNRPC: Remove sock_recvmsg path from svcsock TCP receives

  include/linux/net.h               |  28 +++
  net/sunrpc/svcsock.c              | 381 +++++++++++++++++---------------------
  net/tls/tls.h                     |   3 +
  net/tls/tls_main.c                |   5 +
  net/tls/tls_sw.c                  |  54 +++++-
  tools/testing/selftests/net/tls.c | 298 ++++++++++++++++++++++++++++-
  6 files changed, 556 insertions(+), 213 deletions(-)
---
base-commit: 298bb2b8903323f6ef2eab4819a2e477765f0ff1
change-id: 20260327-tcp-read-sock-778a49660ff7

Best regards,
--
Chuck Lever [off-list ref]

Good stuff. I was tempted to say 'We need it', but meanwhile we found
during spec review that the REPLACETLSPSK mechanism as defined in the
spec is at odds with the TLS KeyUpdate.
So while we (from the NVMe side) might be wanting to use it eventually,
we first have to figure out how to interact sanely between the NVMe
and TLS layer.

And I don't feel qualified to judge on NFS/SunRPC details, so didn't
dare to do a review here.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke                  Kernel Storage Architect
hare@suse.de                                +49 911 74053 688
SUSE Software Solutions GmbH, Frankenstr. 146, 90461 Nürnberg
HRB 36809 (AG Nürnberg), GF: I. Totev, A. McDonald, W. Knoblich