We now have some evidence that PMAP_UNSET clears only "inet" entries, and not "inet6" entries, in the rpcbind database. The svc_unregister() function also must work if user space doesn't support rpcbind version 4 at all. Thus we'll send an rpcbind v4 UNSET, and if that fails, we'll send a PMAP_UNSET. This simplifies the code in svc_unregister() and provides better backwards compatibility with legacy user space that does not support rpcbind version 4. This patch is part of a series that addresses http://bugzilla.kernel.org/show_bug.cgi?id=12256 Signed-off-by: Chuck Lever <chuck.lever@xxxxxxxxxx> Signed-off-by: Steve Dickson <steved@xxxxxxxxxx> --- net/sunrpc/svc.c | 35 ++++++++++++++--------------------- 1 files changed, 14 insertions(+), 21 deletions(-) diff -up linux-2.6.28.x86_64/net/sunrpc/svc.c.orig linux-2.6.28.x86_64/net/sunrpc/svc.c --- linux-2.6.28.x86_64/net/sunrpc/svc.c.orig 2009-02-10 13:14:34.000000000 -0500 +++ linux-2.6.28.x86_64/net/sunrpc/svc.c 2009-02-11 15:02:14.000000000 -0500 @@ -903,15 +903,25 @@ int svc_register(const struct svc_serv * } /* - * Olaf says a v2 UNSET should clear _all_ entries, including any - * registered via a v4 SET + * If user space is running rpcbind, it should take the v4 UNSET + * and clear everything for this [program, version]. If user space + * is running portmap, it will reject the v4 UNSET, but won't have + * any "inet6" entries anyway. So a PMAP_UNSET should be sufficient + * in this case to clear all existing entries for [program, version]. */ static void __svc_unregister(const u32 program, const u32 version, const char *progname) { int error; - error = rpcb_register(program, version, 0, 0); + /* + * User space didn't support rpcbind v4, so retry this + * request with the legacy rpcbind v2 protocol. + */ + error = rpcb_v4_register(program, version, NULL, ""); + if (error == -EPROTONOSUPPORT) + error = rpcb_register(program, version, 0, 0); + dprintk("svc: %s(%sv%u), error %d\n", __func__, progname, version, error); } _______________________________________________ Fedora-kernel-list mailing list Fedora-kernel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-kernel-list
