public inbox for linux-nfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Trond Myklebust <trond.myklebust@fys.uio.no>
To: Chuck Lever <chuck.lever@oracle.com>
Cc: bfields@fieldses.org, linux-nfs@vger.kernel.org
Subject: Re: [PATCH 3/3] SUNRPC: Clearer error message when user space is running portmap
Date: Tue, 13 Jan 2009 12:44:00 -0500	[thread overview]
Message-ID: <1231868640.7036.11.camel@heimdal.trondhjem.org> (raw)
In-Reply-To: <20090113173156.6755.86231.stgit-07a7zB5ZJzbwdl/1UfZZQIVfYA8g3rJ/@public.gmane.org>

On Tue, 2009-01-13 at 12:31 -0500, Chuck Lever wrote:
> Detect the case where we sent an rpcbind v4 SET but user space doesn't
> support rpcbind protocol version 4.
> 
> When registering an AF_INET service, a warning is sent to the log once,
> and we down-shift to version 2.  With AF_INET6, an error is always sent
> to the log, and the registration fails.
> 
> This should help distributors and testers determine why their NFSD
> service won't start, but normal users/admins should really never see
> this message unless something very strange has happened.
> 
> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
> ---
> 
>  net/sunrpc/svc.c |   44 ++++++++++++++++++++++++++++++++++++++------
>  1 files changed, 38 insertions(+), 6 deletions(-)
> 
> diff --git a/net/sunrpc/svc.c b/net/sunrpc/svc.c
> index e93bc55..daed77f 100644
> --- a/net/sunrpc/svc.c
> +++ b/net/sunrpc/svc.c
> @@ -736,6 +736,18 @@ static void __svc_rpcb_prog_mismatch_error(void)
>  	}
>  }
>  
> +static int __svc_rpcb_cant_register(const char *progname, const u32 version)
> +{
> +	printk(KERN_ERR
> +		"svc: Could not register an IPv6 listener for %s v%u "
> +		"with the local portmapper.\n"
> +		"svc: The kernel tried an rpcbind version 4 request, "
> +		"but your portmapper\n"
> +		"svc: does not support rpcbind version 4.",
> +		progname, version);
> +	return -EAFNOSUPPORT;
> +}

This is ___way___ too intrusive...

We already have stuff like the NFSv4 callback channel that automatically
assumes that it should use an IPv6 registration as long as CONFIG_IPV6
or CONFIG_IPV6_MODULE are defined.

Compiling in IPv6 without having an IPv6-capable portmapper should
certainly not be flagged as a kernel error.

>  /*
>   * Register an "inet" protocol family netid with the local
>   * rpcbind daemon via an rpcbind v4 SET request.
> @@ -811,10 +823,14 @@ static int __svc_rpcb_register6(const u32 program, const u32 version,
>  /*
>   * Register a kernel RPC service via rpcbind version 4.
>   *
> + * This logic is complicated by the case where user space is not
> + * running a portmapper that can handle a verison 4 request.
> + *
>   * Returns zero on success; a negative errno value is returned
>   * if any error occurs.
>   */
> -static int __svc_register(const u32 program, const u32 version,
> +static int __svc_register(const char *progname,
> +			  const u32 program, const u32 version,
>  			  const sa_family_t family,
>  			  const unsigned short protocol,
>  			  const unsigned short port)
> @@ -823,11 +839,25 @@ static int __svc_register(const u32 program, const u32 version,
>  
>  	switch (family) {
>  	case AF_INET:
> -		return __svc_rpcb_register4(program, version,
> -						protocol, port);
> +		if (__svc_register_version == 4) {
> +			error = __svc_rpcb_register4(program, version,
> +							protocol, port);
> +			if (error != -EPROTONOSUPPORT)
> +				return error;
> +		}
> +
> +		/* Down-shift. */
> +		__svc_rpcb_prog_mismatch_error();
> +		return rpcb_register(program, version, protocol, port);
>  	case AF_INET6:
> +		/* This won't work if we don't have version 4. */
> +		if (__svc_register_version != 4)
> +			return __svc_rpcb_cant_register(progname, version);
> +
>  		error = __svc_rpcb_register6(program, version,
>  						protocol, port);
> +		if (error == -EPROTONOSUPPORT)
> +			return __svc_rpcb_cant_register(progname, version);
>  		if (error < 0)
>  			return error;
>  
> @@ -854,7 +884,8 @@ static int __svc_register(const u32 program, const u32 version,
>   * Returns zero on success; a negative errno value is returned
>   * if any error occurs.
>   */
> -static int __svc_register(const u32 program, const u32 version,
> +static int __svc_register(const char *progname,
> +			  const u32 program, const u32 version,
>  			  sa_family_t family,
>  			  const unsigned short protocol,
>  			  const unsigned short port)
> @@ -901,8 +932,9 @@ int svc_register(const struct svc_serv *serv, const unsigned short proto,
>  			if (progp->pg_vers[i]->vs_hidden)
>  				continue;
>  
> -			error = __svc_register(progp->pg_prog, i,
> -						serv->sv_family, proto, port);
> +			error = __svc_register(progp->pg_name, progp->pg_prog,
> +						i, serv->sv_family,
> +						proto, port);
>  			if (error < 0)
>  				break;
>  		}
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


  parent reply	other threads:[~2009-01-13 17:44 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-13 17:31 [PATCH 0/3] Detect user space support for rpcbind v4 Chuck Lever
     [not found] ` <20090113172538.6755.83766.stgit-07a7zB5ZJzbwdl/1UfZZQIVfYA8g3rJ/@public.gmane.org>
2009-01-13 17:31   ` [PATCH 1/3] SUNRPC: Don't use EPROTONOSUPPORT in svc_register() Chuck Lever
2009-01-13 17:31   ` [PATCH 2/3] SUNRPC: Clearer error message when user space is running portmap Chuck Lever
2009-01-13 17:31   ` [PATCH 3/3] " Chuck Lever
     [not found]     ` <20090113173156.6755.86231.stgit-07a7zB5ZJzbwdl/1UfZZQIVfYA8g3rJ/@public.gmane.org>
2009-01-13 17:44       ` Trond Myklebust [this message]
     [not found]         ` <1231868640.7036.11.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
2009-01-13 18:26           ` Chuck Lever
2009-01-13 23:13             ` 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=1231868640.7036.11.camel@heimdal.trondhjem.org \
    --to=trond.myklebust@fys.uio.no \
    --cc=bfields@fieldses.org \
    --cc=chuck.lever@oracle.com \
    --cc=linux-nfs@vger.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