[PATCH 0/5] SUNRPC: Receive svcsock TCP records with ->read_sock

kTLS splits a TLS control record across two destinations. The record
type arrives in a control-message buffer. An alert's level and
description land in the buffer the caller set aside for application
data. Every in-kernel consumer thus constructs the same recvmsg()
sequence: install a cmsg buffer, discover mid-call that a control
record arrived, take the body from the data buffer, re-issue the
receive with a kvec, and rewind the iterator that the first copy
advanced.

No consumer has gotten that sequence quite right. tls_alert_recv()
read a kvec holding no valid data on the server side (bee47cb026e7)
and again, found independently, on the client side (cc5d59081fa2).
xprtsock processed only the first cmsg and dropped every record type
behind it (9559d2fffd4f). nvmet-tcp and nvme-tcp were built on the
same split and never took the corresponding repair. bee47cb026e7 was
itself a repair, and it left two more defects that stood for a year
(dbabcbc9cf46, b6c603a2415f).

netdev rejected the read_sock_rectype proto op that would have made
that mistake unrepresentable for every consumer. Instead, this series
fixes the svcsock instance alone. Data records and control records
now arrive through separate calls with separate buffers, and no
buffer carries both application data and record metadata. The
MSG_CTRUNC recovery that bee47cb026e7 installed is removed with the
old path. xprtsock, nvmet-tcp, and nvme-tcp are left for future work.

Classifying a record before consuming it needs a receive that reports
the record type without also deciding what that type means for the
transport. That split sits in front of the conversion (patch 1).

Two types of receive that used to keep a connection running now close
it:

- A handshake record during an established TLS session was drained
  and the receive retried, and svcsock has no handler for a
  post-handshake handshake record.

- ->read_sock stops at an urgent octet and consumes none of it.
  recvmsg() walked past that octet and cleared the condition. So,
  when ingested via read_sock, an RPC stream that carries urgent
  data can no longer advance, and the connection must be dropped.

Signed-off-by: Chuck Lever <[email protected]>

---
Chuck Lever (5):
      SUNRPC: Separate the TLS control-record receive from its policy
      SUNRPC: Close the transport on an unhandled TLS record type
      SUNRPC: Flush a received record's pages once it is complete
      SUNRPC: Receive RPC records with ->read_sock
      SUNRPC: Bypass sock_recvmsg() for the TLS control-record receive

 net/sunrpc/svcsock.c | 555 +++++++++++++++++++++++++++------------------------
 1 file changed, 295 insertions(+), 260 deletions(-)
---
base-commit: 01c2994ccb0197cb44b0db89aacab460110f6347
change-id: 20260821-tls-read-sock-2-28c236db7037

Best regards,
--  
Chuck Lever <[email protected]>