From mboxrd@z Thu Jan 1 00:00:00 1970 From: Al Viro Subject: Re: [RFC][PATCH] nfsd regression since delayed fput() Date: Thu, 17 Oct 2013 21:12:07 +0100 Message-ID: <20131017201207.GT13318@ZenIV.linux.org.uk> References: <20131016185209.GO13318@ZenIV.linux.org.uk> <20131017181457.GA6987@fieldses.org> <20131017183952.GS13318@ZenIV.linux.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "J. Bruce Fields" , linux-fsdevel To: Linus Torvalds Return-path: Received: from zeniv.linux.org.uk ([195.92.253.2]:60049 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1762502Ab3JQUML (ORCPT ); Thu, 17 Oct 2013 16:12:11 -0400 Content-Disposition: inline In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 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...