On Thu, Oct 17, 2013 at 11:39 AM, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote:
>
> Yes, but... To get anything of that kind you would need to have a kernel
> thread open a file on such fs, do IO and fput() it, then have something attempt
> to unlink() it and fail with EBUSY due to fput() being delayed. If that
> something is *not* the same kernel thread, it's already racy
Umm. Let me remind you why this thing got started in the first place.
- the kernel thread is "knfsd"
- the "IO and fput" is a read over NFS
- the unlink is an NFS unlink operation
Yeah, that wasn't so hard to trigger after all, was it? It's just a
client that reads a file and unlinks it within less than a jiffy of
reading it. Boom.
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).
Again, the above is an *example* of subtle issues with delaying the fput.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
