[PATCH] NFS sillyrename fixes (was: [PATCH] nfs_unlink() race)

From: Frank Cusack (fcusack@fcusack.com)
Date: Wed Jun 11 2003 - 02:22:26 EST


On Wed, Jun 11, 2003 at 04:00:41AM +0100, viro@parcelfarce.linux.theplanet.co.uk wrote:
> FWIW, we could probably simply do the following: have nfs_lookup()
> return ERR_PTR(-EINVAL) if it notices that it's about to give us
> such alias. IOW, no access to such guys at all - if it's going
> to die, we refuse to do anything with it. I'll try to do that
> variant when I get some sleep - I'd rather not mess with anything
> in that area until I'm completely awake...

Sounds ok to me, except that Linus says

On Tue, Jun 10, 2003 at 10:30:10PM -0700, Linus Torvalds wrote:
>
> On Wed, 11 Jun 2003 viro@parcelfarce.linux.theplanet.co.uk wrote:
> >
> > Two different dentries for the same file is obviously not a problem...
>
> It _is_ a problem. It does the wrong thing on any subsequent directory
> operation (move or unlink).
>
> Multiple aliased dentries have never been ok, unless the filesystem
> explicitly handles them and invalidates them (ie ntfs/fat kind of things).

so anyway, please find attached a 2.4.21-rc7 and 2.5.70 patch which
prevents removal or rename of unlinked-but-open files. You can see
the rename bug by doing something like

mkdir d1 d2
hold a file open in d1 and rm it; it gets sillyrenamed
move sillyrenamed file to d2
rmdir d1
close file => "inode number mismatch" (data->dir isn't "live", ie it
doesn't follow the rename, and d1 is gone)

/fc





-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Sun Jun 15 2003 - 22:00:27 EST