Hi Justin,
On Tue, 02 Sep 2025, Justin Worrell wrote:
> xs_sock_recv_cmsg was failing to call xs_sock_process_cmsg for any cmsg type
> other than TLS_RECORD_TYPE_ALERT (TLS_RECORD_TYPE_DATA, and other values not
> handled.) Based on my reading of the previous commit (cc5d5908: sunrpc: fix
> client side handling of tls alerts), it looks like only iov_iter_revert
> should be conditional on TLS_RECORD_TYPE_ALERT (but that other cmsg types
> should still call xs_sock_process_cmsg). On my machine, I was unable to
> connect (over mtls) to an NFS share hosted on FreeBSD. With this patch
> applied, I am able to mount the share again.
>
> ---
> diff --git a/net/sunrpc/xprtsock.c b/net/sunrpc/xprtsock.c
> --- a/net/sunrpc/xprtsock.c (revision
> b320789d6883cc00ac78ce83bccbfe7ed58afcf0)
> +++ b/net/sunrpc/xprtsock.c (date 1756813457481)
> @@ -407,9 +407,9 @@
> iov_iter_kvec(&msg.msg_iter, ITER_DEST, &alert_kvec, 1,
> alert_kvec.iov_len);
> ret = sock_recvmsg(sock, &msg, flags);
> - if (ret > 0 &&
> - tls_get_record_type(sock->sk, &u.cmsg) == TLS_RECORD_TYPE_ALERT) {
> - iov_iter_revert(&msg.msg_iter, ret);
> + if (ret > 0) {
> + if (tls_get_record_type(sock->sk, &u.cmsg) == TLS_RECORD_TYPE_ALERT)
> + iov_iter_revert(&msg.msg_iter, ret);
> ret = xs_sock_process_cmsg(sock, &msg, msg_flags, &u.cmsg,
> -EAGAIN);
> }
>
I set up a freebsd server and can reproduce the mount failure from a
linux client (both with xprtsec=tls and xprtsec=mtls).
Your changes look alright to me, but I can't actually apply your patch.
How was the patch generated? There's a line break in the middle of
the from-file line (plus I've never seen the "revision" and "date" text
in the from-file and to-file lines in the patch header before... but
maybe I haven't paid enough attention). Finally, every context line
seems to have an extra space or two.
If I make your changes manually, it fixes mounting with both xprtsec=tls
and xprtsec=mtls.
-Scott
