Re: [PATCH] nfsd: fix handling of readdir in v4root vs. mount upcall timeout

[Ian Kent <raven@themaw.net>]

On 14/12/22 04:02, Jeff Layton wrote:
> On Tue, 2022-12-13 at 19:00 +0000, Chuck Lever III wrote:
>>> On Dec 13, 2022, at 1:08 PM, Jeff Layton <jlayton@kernel.org> wrote:
>>>
>>> If v4 READDIR operation hits a mountpoint and gets back an error,
>>> then it will include that entry in the reply and set RDATTR_ERROR for it
>>> to the error.
>>>
>>> That's fine for "normal" exported filesystems, but on the v4root, we
>>> need to be more careful to only expose the existence of dentries that
>>> lead to exports.
>>>
>>> If the mountd upcall times out while checking to see whether a
>>> mountpoint on the v4root is exported, then we have no recourse other
>>> than to fail the whole operation.
>> Thank you for chasing this down!
>>
>> Failing the whole READDIR when mountd times out might be a bad idea.
>> If the mountd upcall times out every time, the client can't make
>> any progress and will continue to emit the failing READDIR request.
>>
>> Would it be better to skip the unresolvable entry instead and let
>> the READDIR succeed without that entry?
>>
> Mounting doesn't usually require working READDIR. In that situation, a
> readdir() might hang (until the client kills), but a lookup of other
> dentries that aren't perpetually stalled should be ok in this situation.
>
> If mountd is that hosed then I think it's unlikely that any progress
> will be possible anyway.

The READDIR shouldn't trigger a mount yes, but if it's a valid automount

point (basically a valid dentry in this case I think) it should be listed.

It certainly shouldn't hold up the READDIR, passing into it is when a

mount should occur.


That's usually the behavior we want for automounts, we don't want mount

storms on directories full of automount points.


Ian