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 <[email protected]>
