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: Fri, 14 Aug 2026 07:01:55 -0400 [thread overview]
Message-ID: <a8f5840cf3f2cbf71de7a1f3957f70d9897adfa2.camel@kernel.org> (raw)
In-Reply-To: <572f0269-9bf4-4a80-8e9c-3c4614d45f7e@app.fastmail.com>
On Wed, 2026-08-12 at 15:57 -0400, Chuck Lever wrote:
>
> On Wed, Aug 12, 2026, at 3:38 PM, Jeff Layton wrote:
> > On Tue, 2026-08-11 at 15:19 -0400, Chuck Lever wrote:
>
> > > 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.
>
> I was thinking of this in terms of a declarative administrative UI:
> If the kernel can't set the requested configuration, it should
> fail back to the previous configuration. Maybe that's not possible.
>
It's possible, but difficult. The original /proc interfaces were never
this clean, so making the underlying bits behave this way for the
netlink interfaces, but not the legacy /proc ones will be hard.
Also, today we don't take any steps to try and preserve the old
listener table. That would have to be done here as well.
> On the other hand, what might be better is to handle the rpcbind
> registration from user space instead of the kernel, after the
> kernel listener is set up.
>
That's possible I guess. We could send a new boolean down in the
listener call that says "don't do any rpcbind registration" and then if
the kernel indicates that it understands that message then userland
could do the registration.
That's a major undertaking though and I don't like fundamentally
changing the interface here, particularly when we'll still have to cope
with doing this from the kernel for legacy cases.
I still think the best solution of all would be to just say
"henceforth, rpcbind registration is non-fatal". That just leaves the
kernel succeeding the listener set today when it would have failed
before, but will still printk() an appropriate warning in that case, so
the admin should be aware that rpcbind registration failed, even though
the server is up.
Right now, I'm really unclear on what sort of changes you want to see
here as a final patchset. What would make this mergeable for you?
--
Jeff Layton <jlayton@kernel.org>
next prev parent reply other threads:[~2026-08-14 11:02 UTC|newest]
Thread overview: 15+ 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
2026-08-12 19:57 ` Chuck Lever
2026-08-14 11:01 ` Jeff Layton [this message]
2026-08-14 15:28 ` 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=a8f5840cf3f2cbf71de7a1f3957f70d9897adfa2.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.