From: "Chuck Lever" <cel@kernel.org>
To: "Jeff Layton" <jlayton@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:57:52 -0400 [thread overview]
Message-ID: <572f0269-9bf4-4a80-8e9c-3c4614d45f7e@app.fastmail.com> (raw)
In-Reply-To: <26486c88075a0b1e3c1cb088fe97d39e0051b5d3.camel@kernel.org>
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.
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.
--
Chuck Lever
next prev parent reply other threads:[~2026-08-12 19:58 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 [this message]
2026-08-14 11:01 ` Jeff Layton
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=572f0269-9bf4-4a80-8e9c-3c4614d45f7e@app.fastmail.com \
--to=cel@kernel.org \
--cc=Dai.Ngo@oracle.com \
--cc=anna@kernel.org \
--cc=bfields@fieldses.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=jlayton@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
all inboxes | Powered by JetHome®