From: Jeff Layton <jlayton@kernel.org>
To: Olga Kornievskaia <okorniev@redhat.com>, chuck.lever@oracle.com
Cc: linux-nfs@vger.kernel.org, neil@brown.name, Dai.Ngo@oracle.com,
tom@talpey.com
Subject: Re: [PATCH 1/1] nfsd: unregister with rpcbind when deleting a transport
Date: Mon, 18 Aug 2025 16:10:23 -0400 [thread overview]
Message-ID: <79c73f4749a2f0c8435f159d72fc30d11fa03cdc.camel@kernel.org> (raw)
In-Reply-To: <20250818182557.11259-1-okorniev@redhat.com>
On Mon, 2025-08-18 at 14:25 -0400, Olga Kornievskaia wrote:
> When a listener is added, a part of creation of transport also registers
> program/port with rpcbind. However, when the listener is removed,
> while transport goes away, rpcbind still has the entry for that
> port/type.
>
> When deleting the transport, unregister with rpcbind when appropriate.
>
> Fixes: d093c9089260 ("nfsd: fix management of listener transports")
> Signed-off-by: Olga Kornievskaia <okorniev@redhat.com>
> ---
> net/sunrpc/svc_xprt.c | 17 +++++++++++++++++
> 1 file changed, 17 insertions(+)
>
> diff --git a/net/sunrpc/svc_xprt.c b/net/sunrpc/svc_xprt.c
> index 8b1837228799..223737fac95d 100644
> --- a/net/sunrpc/svc_xprt.c
> +++ b/net/sunrpc/svc_xprt.c
> @@ -1014,6 +1014,23 @@ static void svc_delete_xprt(struct svc_xprt *xprt)
> struct svc_serv *serv = xprt->xpt_server;
> struct svc_deferred_req *dr;
>
> + /* unregister with rpcbind for when transport type is TCP or UDP.
> + * Only TCP and RDMA sockets are marked as LISTENER sockets, so
> + * check for UDP separately.
> + */
> + if ((test_bit(XPT_LISTENER, &xprt->xpt_flags) &&
> + xprt->xpt_class->xcl_ident != XPRT_TRANSPORT_RDMA) ||
> + xprt->xpt_class->xcl_ident == XPRT_TRANSPORT_UDP) {
> + struct svc_sock *svsk = container_of(xprt, struct svc_sock,
> + sk_xprt);
> + struct socket *sock = svsk->sk_sock;
> +
> + if (svc_register(serv, xprt->xpt_net, sock->sk->sk_family,
> + sock->sk->sk_protocol, 0) < 0)
> + pr_warn("failed to unregister %s with rpcbind\n",
> + xprt->xpt_class->xcl_name);
> + }
> +
> if (test_and_set_bit(XPT_DEAD, &xprt->xpt_flags))
> return;
>
This looks good to me. Doing it this way may be preferable if we ever
get around to allowing the removal of listeners while the server is
running.
Reviewed-by: Jeff Layton <jlayton@kernel.org>
prev parent reply other threads:[~2025-08-18 20:10 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-18 18:25 [PATCH 1/1] nfsd: unregister with rpcbind when deleting a transport Olga Kornievskaia
2025-08-18 18:46 ` Chuck Lever
2025-08-18 18:55 ` Olga Kornievskaia
2025-08-18 19:04 ` Olga Kornievskaia
2025-08-18 19:36 ` Chuck Lever
2025-08-18 20:47 ` Chuck Lever
2025-08-19 15:14 ` Olga Kornievskaia
2025-08-19 15:14 ` Olga Kornievskaia
2025-08-19 15:28 ` Chuck Lever
2025-08-19 16:07 ` Tom Talpey
2025-08-18 20:10 ` Jeff Layton [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=79c73f4749a2f0c8435f159d72fc30d11fa03cdc.camel@kernel.org \
--to=jlayton@kernel.org \
--cc=Dai.Ngo@oracle.com \
--cc=chuck.lever@oracle.com \
--cc=linux-nfs@vger.kernel.org \
--cc=neil@brown.name \
--cc=okorniev@redhat.com \
--cc=tom@talpey.com \
/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