Thread (15 messages) flat view 15 messages, 2 authors, 20d ago

Re: [PATCH v2 4/8] SUNRPC: undo partial rpcbind registrations when svc_register() fails

From: Jeff Layton <jlayton@kernel.org>
Date: 2026-08-14 11:02:02
Also in: linux-kselftest, linux-nfs, lkml

On Wed, 2026-08-12 at 15:57 -0400, Chuck Lever wrote:
On Wed, Aug 12, 2026, at 3:38 PM, Jeff Layton wrote:
quoted
On Tue, 2026-08-11 at 15:19 -0400, Chuck Lever wrote:
quoted
quoted
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 [off-list ref]
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help