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/[email protected]
---
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 <[email protected]>
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
[email protected] +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
