From: Chuck Lever <cel@kernel.org>
To: Trond Myklebust <trondmy@kernel.org>,
Anna Schumaker <anna@kernel.org>, Chuck Lever <cel@kernel.org>,
Jeff Layton <jlayton@kernel.org>, NeilBrown <neil@brown.name>,
Olga Kornievskaia <okorniev@redhat.com>,
Dai Ngo <Dai.Ngo@oracle.com>, Tom Talpey <tom@talpey.com>
Cc: linux-nfs@vger.kernel.org, netdev@vger.kernel.org
Subject: [PATCH 8/8] SUNRPC: fold xs_sock_process_cmsg() into its only caller
Date: Wed, 05 Aug 2026 14:30:59 -0400 [thread overview]
Message-ID: <20260805-svcsock-cmsg-fixes-v1-8-43514a32da9b@kernel.org> (raw)
In-Reply-To: <20260805-svcsock-cmsg-fixes-v1-0-43514a32da9b@kernel.org>
xs_sock_process_cmsg() switches on the TLS record type, and every arm
but TLS_RECORD_TYPE_ALERT returns the -EAGAIN its caller passed in.
The DATA arm clears MSG_EOR in the caller's msghdr, but
xs_sock_recvmsg() has already cleared that flag before the call.
Deriving the record type a second time inside the helper also fires
trace_tls_contenttype() twice for every alert.
Move the alert handling into xs_sock_recv_cmsg() and delete the
helper. Every other record type still returns -EAGAIN. The DATA arm's
account of MSG_EOR moves to xs_sock_recvmsg(), where the flag is
cleared.
Signed-off-by: Chuck Lever <cel@kernel.org>
---
net/sunrpc/xprtsock.c | 85 ++++++++++++++++++---------------------------------
1 file changed, 30 insertions(+), 55 deletions(-)
diff --git a/net/sunrpc/xprtsock.c b/net/sunrpc/xprtsock.c
index 5527f7f8a185..38dd75a23af7 100644
--- a/net/sunrpc/xprtsock.c
+++ b/net/sunrpc/xprtsock.c
@@ -356,45 +356,6 @@ xs_alloc_sparse_pages(struct xdr_buf *buf, size_t want, gfp_t gfp)
return want;
}
-static int
-xs_sock_process_cmsg(struct socket *sock, struct msghdr *msg,
- unsigned int *msg_flags, struct cmsghdr *cmsg, int ret)
-{
- u8 content_type = tls_get_record_type(sock->sk, cmsg);
- u8 level, description;
-
- switch (content_type) {
- case 0:
- break;
- case TLS_RECORD_TYPE_DATA:
- /* TLS sets EOR at the end of each application data
- * record, even though there might be more frames
- * waiting to be decrypted.
- */
- *msg_flags &= ~MSG_EOR;
- break;
- case TLS_RECORD_TYPE_ALERT:
- tls_alert_recv(sock->sk, msg, &level, &description);
- /* RFC 8446 Section 6: every alert but a closure alert is
- * an error alert, whatever the legacy AlertLevel octet
- * says.
- */
- switch (description) {
- case TLS_ALERT_DESC_CLOSE_NOTIFY:
- case TLS_ALERT_DESC_USER_CANCELED:
- ret = -EAGAIN;
- break;
- default:
- ret = -EACCES;
- }
- break;
- default:
- /* discard this record type */
- ret = -EAGAIN;
- }
- return ret;
-}
-
static int
xs_sock_recv_cmsg(struct socket *sock, unsigned int *msg_flags, int flags)
{
@@ -412,6 +373,7 @@ xs_sock_recv_cmsg(struct socket *sock, unsigned int *msg_flags, int flags)
.msg_control = &u,
.msg_controllen = sizeof(u),
};
+ u8 level, description;
int ret;
iov_iter_kvec(&msg.msg_iter, ITER_DEST, &alert_kvec, 1,
@@ -421,23 +383,32 @@ xs_sock_recv_cmsg(struct socket *sock, unsigned int *msg_flags, int flags)
* kTLS filled in u.cmsg.
*/
if (ret >= 0 && msg.msg_controllen < sizeof(u)) {
- if (tls_get_record_type(sock->sk, &u.cmsg) ==
- TLS_RECORD_TYPE_ALERT) {
- /* RFC 8446 Section 5.1 requires a record with an
- * Alert type to carry exactly one message. An alert
- * is two octets. tls_alert_recv() reads both without
- * checking the length. alert_kvec caps the count at
- * two, so a longer record fills it as well. kTLS
- * sets MSG_EOR only once the record has been
- * drained.
- */
- if (ret != sizeof(alert) ||
- !(msg.msg_flags & MSG_EOR))
- return -EACCES;
- iov_iter_revert(&msg.msg_iter, ret);
+ if (tls_get_record_type(sock->sk, &u.cmsg) !=
+ TLS_RECORD_TYPE_ALERT)
+ return -EAGAIN;
+ /* RFC 8446 Section 5.1: a record with an Alert type carries
+ * exactly one message, and an alert is two octets.
+ * tls_alert_recv() reads both without checking the length.
+ * alert_kvec caps the count at two, so a longer record
+ * fills it as well. kTLS sets MSG_EOR only once the
+ * record has been drained.
+ */
+ if (ret != sizeof(alert) || !(msg.msg_flags & MSG_EOR))
+ return -EACCES;
+ iov_iter_revert(&msg.msg_iter, ret);
+ tls_alert_recv(sock->sk, &msg, &level, &description);
+ /* RFC 8446 Section 6: every alert but a closure alert is
+ * an error alert, whatever the legacy AlertLevel octet
+ * says.
+ */
+ switch (description) {
+ case TLS_ALERT_DESC_CLOSE_NOTIFY:
+ case TLS_ALERT_DESC_USER_CANCELED:
+ ret = -EAGAIN;
+ break;
+ default:
+ ret = -EACCES;
}
- ret = xs_sock_process_cmsg(sock, &msg, msg_flags, &u.cmsg,
- -EAGAIN);
}
return ret;
}
@@ -451,6 +422,10 @@ xs_sock_recvmsg(struct socket *sock, struct msghdr *msg, int flags, size_t seek)
ret = sock_recvmsg(sock, msg, flags);
/* Handle TLS inband control message lazily */
if (msg->msg_flags & MSG_CTRUNC) {
+ /* TLS sets EOR at the end of each application data
+ * record, even though there might be more frames
+ * waiting to be decrypted.
+ */
msg->msg_flags &= ~(MSG_CTRUNC | MSG_EOR);
if (ret == 0 || ret == -EIO)
ret = xs_sock_recv_cmsg(sock, &msg->msg_flags, flags);
--
2.54.0
prev parent reply other threads:[~2026-08-05 18:31 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-05 18:30 [PATCH 0/8] SUNRPC: Fix TLS control record handling Chuck Lever
2026-08-05 18:30 ` [PATCH 1/8] SUNRPC: treat every TLS error alert as fatal Chuck Lever
2026-08-05 18:30 ` [PATCH 2/8] SUNRPC: do not credit control-record octets to the RPC stream Chuck Lever
2026-08-05 18:30 ` [PATCH 3/8] SUNRPC: reject a TLS alert record that is not two octets Chuck Lever
2026-08-05 18:30 ` [PATCH 4/8] SUNRPC: resume receiving after a TLS control record Chuck Lever
2026-08-05 18:30 ` [PATCH 5/8] SUNRPC: fold svc_tcp_sock_process_cmsg() into its only caller Chuck Lever
2026-08-05 18:30 ` [PATCH 6/8] SUNRPC: treat every client-side TLS error alert as fatal Chuck Lever
2026-08-05 18:30 ` [PATCH 7/8] SUNRPC: reject a client-side TLS alert record that is not two octets Chuck Lever
2026-08-05 18:30 ` Chuck Lever [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260805-svcsock-cmsg-fixes-v1-8-43514a32da9b@kernel.org \
--to=cel@kernel.org \
--cc=Dai.Ngo@oracle.com \
--cc=anna@kernel.org \
--cc=jlayton@kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=neil@brown.name \
--cc=netdev@vger.kernel.org \
--cc=okorniev@redhat.com \
--cc=tom@talpey.com \
--cc=trondmy@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox