Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) client-ip=2620:137:e000::3:3;
From:   NeilBrown <neilb@suse.de>
To:     Steve Dickson <steved@redhat.com>
Cc:     linux-nfs@vger.kernel.org,
        Trond Myklebust <trondmy@hammerspace.com>
Subject: [PATCH 0/3 nfs-utils] fixes for error handling in nfsd_fh
Date:   Wed, 11 Oct 2023 15:57:59 +1100
Message-ID: <20231011051131.24667-1-neilb@suse.de>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Precedence: bulk

When the kernel ask mountd to map the fsid from a filehandle to a path
name the request is handled by nfsd_fh().
The kernel expects to get a definitive answer - either a path name or
an clear statement that there is no path name.  However mountd sometimes cannot 
give a definitive answer - it wants to say "ask again later", but it cannot.

One case that it wants to say "ask again" is when a 'stat' of a
mountpoint fails with a non-path-name error.  This might mean that a
re-exported NFS mount is having problems.

The code for handling this case is incorrect.  mountd potentially scan
every moint point.  If any mount point matches the fsid, it should
succeed even if some other mountpoint appears to have problems.  Instead
assumes failure is *any* mountpoint has problems.  The first patch fixes
this - so now the error handling is only triggered if no matching mount
can be found.

This list of errors that are considered "path-name errors" does not
included EACCES.  This error can be returned, e.g., by fuse filesystem
that only allow a single use to have access.  The should be treated as a
path-name error.  The second patch fixes this.

However this still leave the error handling to be wrong.  The response
when no match is found and at least one questionable path is seen, is to
not send a response to the kernel.  The result of this is that the
kernel never asks again.  It return NFS4ERR_DELAY (for NFSv4) to the
client, but doesn't ever re-queue the request as the request is already
queued.  There is no way to tell the kernel "dequeue this request treat
the lookup as failure".

The third patch proposes a machanism to do this.  It returns a negative
result to the kernel with an expiry time in the past.  This could
reasonably be interpreted as "dequeue the request but do return a
definitive result".  The kernel doesn't currently treat it like that.
Rather it treats it as definitive just once, and will ask again for the
next request. But that will only come after the client has seen a failure.

We could easily change the kernel to respond differently, but we would
need to think carefully about the behaviour on older kernels, and about
the possibility of a much higher rate of fsid lookup requests being sent
from kernel to mountd.

So the third patch is just an RFC.  The first two patches are, I think,
suitable for immediate release (subject to normal review).

Thanks,
NeilBrown