mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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>,
	"Shuah Khan" <shuah@kernel.org>
Cc: "Slawomir Stepien" <sst@poczta.fm>,
	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 v3 06/14] SUNRPC: report local rpcbind calls that get no answer
Date: Sun, 30 Aug 2026 11:51:27 -0400	[thread overview]
Message-ID: <c42d685f-18e7-4f38-8ce2-3d8e5402e9f1@app.fastmail.com> (raw)
In-Reply-To: <20260828-nfsd-nl-hang-v3-6-55026685c75d@kernel.org>



On Fri, Aug 28, 2026, at 12:37 PM, Jeff Layton wrote:
> A caller that creates many listeners in one operation calls svc_register()
> once for each of them. Every call waits for the local rpcbind on its own,
> so a rpcbind that never answers costs the caller one timeout per listener.
> The caller has no way to learn that the first call already failed.
>
> An rpcbind failure can occur one of two ways: either rpcbind fails to
> respond, or it can respond with -EACCES to indicate that the user
> doesn't own the current record.
>
> Give the first case its own errno. rpcb_register_call() returns -ENAVAIL
> when the call got no answer, and the existing -EACCES continues to mean a
> FALSE reply.
>
> svc_generic_rpcbind_set() has to let -ENAVAIL past vs_rpcb_optnl, since it
> is not a refusal. svc_register() applies vs_rpcb_optnl to it instead, so a
> v4-only server still creates its listeners, and then keeps a running total
> in serv->sv_rpcb_failures. -ENAVAIL never escapes svc_register().
>
> svc_rpcb_failure_count() reports the total. A caller reads the count
> before it starts and compares as it goes to determine if there have been
> errors.
>
> The users of this infrastructure will be added in later patches.
>
> Assisted-by: LLM
> Signed-off-by: Jeff Layton <jlayton@kernel.org>

> diff --git a/net/sunrpc/rpcb_clnt.c b/net/sunrpc/rpcb_clnt.c
> index 0aa376b82a52..c680137f0fca 100644
> --- a/net/sunrpc/rpcb_clnt.c
> +++ b/net/sunrpc/rpcb_clnt.c
> @@ -412,7 +412,8 @@ static struct rpc_clnt *rpcb_create(struct net 
> *net, const char *nodename,
>  	return rpc_create(&args);
>  }
> 
> -static int rpcb_register_call(struct sunrpc_net *sn, struct rpc_clnt 
> *clnt, struct rpc_message *msg, bool is_set)
> +static int rpcb_register_call(struct sunrpc_net *sn, struct rpc_clnt 
> *clnt,
> +			      struct rpc_message *msg, bool is_set)
>  {
>  	int flags = RPC_TASK_NOCONNECT;
>  	int error, result = 0;
> @@ -422,8 +423,10 @@ static int rpcb_register_call(struct sunrpc_net 
> *sn, struct rpc_clnt *clnt, stru
>  	msg->rpc_resp = &result;
> 
>  	error = rpc_call_sync(clnt, msg, flags);
> -	if (error < 0)
> +	if (error == -EPROTONOSUPPORT)
>  		return error;
> +	if (error < 0)
> +		return -ENAVAIL;
> 
>  	if (!result)
>  		return -EACCES;

If I'm reading this correctly, rpcb_register_call() classifies
every failure except -EPROTONOSUPPORT as "no answer".

rpc_call_sync() returns negative errnos that are not "no answer":
pre-dispatch local failures (-ENOMEM from rpc_new_task()), a fatal
signal (-ERESTARTSYS), and reply-derived errors from
rpc_verify_header(): -EPFNOSUPPORT, -EOPNOTSUPP, -EIO, -EACCES
(auth error), -EKEYREJECTED. All of these show that rpcbind *did*
answer.

Now they become -ENAVAIL, get counted in sv_rpcb_failures, are
silently converted to success for a vs_rpcb_optnl version, and
reach userspace as a synthesized -ETIMEDOUT for mandatory versions.

Consequences:

* The commit message says "-EACCES continues to mean a FALSE
  reply," but the RPC layer's auth -EACCES is rewritten to
  -ENAVAIL before the two can be told apart. Its "one of two
  ways" failure taxonomy is not what the code implements.

* "rpcbind not running" (-ECONNREFUSED/-ENOENT) and every
  other transport error reach nfsd's listener_set ack, the
  svc_register/svc_unregister tracepoints, and the printk
  as indistinguishable ETIMEDOUT/ENAVAIL, which IMO is an
  observability regression.

* -ERESTARTSYS -> -ETIMEDOUT drops syscall-restart semantics
  on a fatal signal during registration.

I'm probably missing something.


-- 
Chuck Lever (Come to NFS bake-a-thon! https://nfsv4bat.org)

  reply	other threads:[~2026-08-30 15:51 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-28 16:37 [PATCH v3 00/14] nfsd/sunrpc: harden the netlink listener set interface Jeff Layton
2026-08-28 16:37 ` [PATCH v3 01/14] NFSD: cap the number of listeners accepted in listener_set Jeff Layton
2026-08-28 16:37 ` [PATCH v3 02/14] NFSD: validate transport name in listener_set before serv creation Jeff Layton
2026-08-28 16:37 ` [PATCH v3 03/14] SUNRPC: keep the first error in svc_register() Jeff Layton
2026-08-28 16:37 ` [PATCH v3 04/14] SUNRPC: bound the local rpcbind client timeout to 1s Jeff Layton
2026-08-28 16:37 ` [PATCH v3 05/14] NFSD: report listener creation failures through extack Jeff Layton
2026-08-28 16:37 ` [PATCH v3 06/14] SUNRPC: report local rpcbind calls that get no answer Jeff Layton
2026-08-30 15:51   ` Chuck Lever [this message]
2026-08-31 12:05     ` Jeff Layton
2026-08-28 16:37 ` [PATCH v3 07/14] SUNRPC: stop svc_register() once rpcbind stops answering Jeff Layton
2026-08-28 16:37 ` [PATCH v3 08/14] SUNRPC: stop the svc_unregister() sweep " Jeff Layton
2026-08-28 16:37 ` [PATCH v3 09/14] SUNRPC: stop unregistering listeners " Jeff Layton
2026-08-28 16:37 ` [PATCH v3 10/14] NFSD: stop registering with rpcbind after a failure in listener_set Jeff Layton
2026-08-28 16:37 ` [PATCH v3 11/14] selftests/nfsd: exercise listener_set request validation Jeff Layton
2026-08-28 16:37 ` [PATCH v3 12/14] selftests/nfsd: add a per-netns rpcbind stub and the listener round-trips Jeff Layton
2026-08-28 16:37 ` [PATCH v3 13/14] selftests/nfsd: check that listener_set asks rpcbind once Jeff Layton
2026-08-28 16:37 ` [PATCH v3 14/14] selftests/nfsd: check that listener removal " Jeff Layton

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=c42d685f-18e7-4f38-8ce2-3d8e5402e9f1@app.fastmail.com \
    --to=cel@kernel.org \
    --cc=Dai.Ngo@oracle.com \
    --cc=anna@kernel.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=sst@poczta.fm \
    --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®