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
