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

[Chuck Lever <cel@kernel.org>]

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 <cel@kernel.org>