Netdev List
 help / color / mirror / Atom feed
From: Jeff Layton <jlayton@kernel.org>
To: Chuck Lever <cel@kernel.org>, NeilBrown <neil@brown.name>,
	Olga Kornievskaia <okorniev@redhat.com>,
	Dai Ngo <Dai.Ngo@oracle.com>, Tom Talpey <tom@talpey.com>,
	Trond Myklebust <trondmy@kernel.org>,
	Anna Schumaker <anna@kernel.org>,
	"David S. Miller"	 <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski	 <kuba@kernel.org>,
	Paolo Abeni <pabeni@redhat.com>, Simon Horman	 <horms@kernel.org>,
	"J. Bruce Fields" <bfields@fieldses.org>,
	Shuah Khan	 <shuah@kernel.org>
Cc: linux-nfs@vger.kernel.org, linux-kernel@vger.kernel.org,
	 netdev@vger.kernel.org, Trond Myklebust <trondmy@gmail.com>,
	 linux-kselftest@vger.kernel.org
Subject: Re: [PATCH v2 4/8] SUNRPC: undo partial rpcbind registrations when svc_register() fails
Date: Wed, 12 Aug 2026 15:38:44 -0400	[thread overview]
Message-ID: <26486c88075a0b1e3c1cb088fe97d39e0051b5d3.camel@kernel.org> (raw)
In-Reply-To: <e1706a70-d9f8-423e-9462-2d77b2e444b1@app.fastmail.com>

On Tue, 2026-08-11 at 15:19 -0400, Chuck Lever wrote:
> 
> On Tue, Aug 11, 2026, at 8:03 AM, Jeff Layton wrote:
> > svc_register() registers each [program, version] in turn. On failure the
> > caller tears the listener down -- svc_setup_socket() frees the svc_sock and
> > svc_create_socket() releases the socket -- but the entries that were already
> > set stay in rpcbind, now pointing at a closed port. XPT_RPCB_UNREG is set
> > later, in svc_udp_init()/svc_tcp_init(), so svc_delete_xprt() never runs for
> > this transport and nothing clears them.
> > 
> > Unwind on failure, and stop the walk there rather than registering the
> > programs after it. rpcbind matches RPCBPROC_UNSET on
> > [program, version, netid] and ignores the address, so the unwind clears the
> > netid, not just the port -- the same granularity svc_delete_xprt() already
> > unregisters at.
> > 
> > Assisted-by: LLM
> > Signed-off-by: Jeff Layton <jlayton@kernel.org>
> > ---
> >  net/sunrpc/svc.c | 31 ++++++++++++++++++++++++++++++-
> >  1 file changed, 30 insertions(+), 1 deletion(-)
> > 
> > diff --git a/net/sunrpc/svc.c b/net/sunrpc/svc.c
> > index 4f402bbf97ba..9ffa87007004 100644
> > --- a/net/sunrpc/svc.c
> > +++ b/net/sunrpc/svc.c
> > @@ -1183,6 +1183,29 @@ int svc_generic_rpcbind_set(struct net *net,
> >  }
> >  EXPORT_SYMBOL_GPL(svc_generic_rpcbind_set);
> > 
> > +/*
> > + * Undo the [program, version] registrations that this svc_register() 
> > call
> > + * already made, stopping at version @nvers of program @nprog.
> > + *
> > + * Note that rpcbind matches RPCBPROC_UNSET on [program, version, 
> > netid] and
> > + * ignores the address, so this clears the netid rather than the one 
> > port.
> > + * That is the granularity svc_delete_xprt() unregisters at as well.
> > + */
> > +static void svc_unwind_register(const struct svc_serv *serv, struct 
> > net *net,
> > +				const int family, const unsigned short proto,
> > +				unsigned int nprog, unsigned int nvers)
> > +{
> > +	unsigned int p, i;
> > +
> > +	for (p = 0; p <= nprog; p++) {
> > +		struct svc_program *progp = &serv->sv_programs[p];
> > +		unsigned int last = p < nprog ? progp->pg_nvers : nvers;
> > +
> > +		for (i = 0; i < last; i++)
> > +			progp->pg_rpcbind_set(net, progp, i, family, proto, 0);
> > +	}
> > +}
> 
> For an IPv4 listener, the port-zero callback falls back through
> __svc_rpcb_register4() to rpcb_register(). PMAPPROC_UNSET ignores
> its protocol argument, so unwinding a partially successful TCP
> registration also removes the mappings for existing listeners on
> other transports, I would think.
> 
> It might be that the best the kernel can do here is tear everything
> down if one registration fails.
> 

What I was thinking for NFSv2/3 was to just have the listener set
netlink call wait for registration to complete before returning to
userland. That would mean we'd have to block even longer to try and
unregister things if things fail.

Alternate proposal: let's just declare rpcbind reg errors to be non-
fatal: do a pr_warn() and just leave it up to the admin to sort it out
if that happens instead of trying to fail the startup.

The resulting situation for the server is no worse off (it's just
running instead of being down), and I move that we're better off
leaving it up to a human to clean up the mess instead of trying to fix
things up from the kernel.

Thoughts?
-- 
Jeff Layton <jlayton@kernel.org>

  reply	other threads:[~2026-08-12 19:38 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-11 12:02 [PATCH v2 0/8] nfsd/sunrpc: harden the netlink listener interfaces Jeff Layton
2026-08-11 12:03 ` [PATCH v2 1/8] NFSD: validate transport name in listener_set before serv creation Jeff Layton
2026-08-11 12:03 ` [PATCH v2 2/8] NFSD: cap the number of listeners accepted in listener_set Jeff Layton
2026-08-11 12:03 ` [PATCH v2 3/8] SUNRPC: keep the first error in svc_register() Jeff Layton
2026-08-11 12:03 ` [PATCH v2 4/8] SUNRPC: undo partial rpcbind registrations when svc_register() fails Jeff Layton
2026-08-11 19:19   ` Chuck Lever
2026-08-12 19:38     ` Jeff Layton [this message]
2026-08-12 19:57       ` Chuck Lever
2026-08-11 12:03 ` [PATCH v2 5/8] SUNRPC: bound the local rpcbind client timeout to 1s Jeff Layton
2026-08-11 12:03 ` [PATCH v2 6/8] NFSD: report listener creation failures through extack Jeff Layton
2026-08-11 12:03 ` [PATCH v2 7/8] selftests/nfsd: exercise listener_set request validation Jeff Layton
2026-08-11 12:03 ` [PATCH v2 8/8] selftests/nfsd: add a per-netns rpcbind stub and the listener round-trips Jeff Layton
2026-08-11 19:14   ` Chuck Lever

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=26486c88075a0b1e3c1cb088fe97d39e0051b5d3.camel@kernel.org \
    --to=jlayton@kernel.org \
    --cc=Dai.Ngo@oracle.com \
    --cc=anna@kernel.org \
    --cc=bfields@fieldses.org \
    --cc=cel@kernel.org \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=horms@kernel.org \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=neil@brown.name \
    --cc=netdev@vger.kernel.org \
    --cc=okorniev@redhat.com \
    --cc=pabeni@redhat.com \
    --cc=shuah@kernel.org \
    --cc=tom@talpey.com \
    --cc=trondmy@gmail.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