On Tue, Sep 2, 2025 at 8:27 AM Justin Worrell <jworrell@xxxxxxxxx> 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.
Thanks for the catch Justin. Indeed, the client fails to return an
error in case it receives anything other than TLS DATA or TLS ALERT.
Could you tell what kind of TLS message the FreeBSD server is sending?
Either a network trace or turning on tls_contentype tracepoint should
show what type the client has been receiving.
> ---
> 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);
> }
>
