Re: [RFC][PATCH] nfsd regression since delayed fput()

[Al Viro <viro@ZenIV.linux.org.uk>]

On Thu, Oct 17, 2013 at 12:09:00PM -0700, Linus Torvalds wrote:
> All it needs is a non-unixy filesystem getting nfs-exported. Like FAT.
> 
> Now, I actually think that FAT is fine with unlinking a file that is
> in use, but my whole argument was "unintended consequences". It is
> *not* obvious that keeping a reference is valid.
>
> Look at rmdir() instead of unlink(), for example. Even POSIX allows
> EBUSY for a directory entry that is still in use, and requires it for
> a non-empty one. So even with a Unix filesystem, I can imagine
> somebody (and by somebody, I mean "knfsd, as response to normal NFS
> client traffic") doing:
> 
>  - read file (delayed fput)
>  - unlink file
>  - rmdir directory that file used to be in and that *should* be empty
>  - delayed fput happens now.
> 
> and even a posix-compliant filesystem could have issues with this
> (again, the *example* for a filesystem with issues would be NFS, and I
> realize you don't re-export it, but the point is, filesystem semantics
> can make this problematic).

Sure, I agree that such a scenario might happen; the question was "which
fs would have to be exported to step on that?" and AFAICS none of the
exportable filesystems have any problems of that sort.
 
> Again, the above is an *example* of subtle issues with delaying the fput.

And we have a tool for dealing with those, if they turn out to be real -
flush_delayed_fput(), doing all pending delayed ones.  I would rather
avoid using it unless we have a case where it's really needed, though;
it can have interesting consequences wrt locking order, etc.

Frankly, in case of knfsd I'm a lot more concerned about the amount of
struct file (all for the same few disk files) sitting around opened and
waiting to be closed, just because there's a client saturating a 10G
link with read requests...