Messages in this thread |  | | Date | Wed, 11 Jun 2003 04:00:41 +0100 | From | viro@parcelfa ... | Subject | Re: [PATCH] nfs_unlink() race (was: nfs_refresh_inode: inode number mismatch) |
| |
On Tue, Jun 10, 2003 at 07:43:33PM -0700, Frank Cusack wrote: > On Wed, Jun 11, 2003 at 03:27:54AM +0100, viro@parcelfarce.linux.theplanet.co.uk wrote: > > On Wed, Jun 11, 2003 at 03:59:10AM +0200, Trond Myklebust wrote: > > > IOW we just want to prevent VFS from unhashing the dentry in the first > > > place: dentry aliasing cannot work together with sillyrename. > > > > Aliasing could be dealt with. They would have the same inode, so it's > > easy to detect. > > dentry only contains the inode, not the fh. On the server, the inode > can go away and come back as a new fh, but with the same inode. Is > that detectable (would comparison hooks have to be added?)? Although, > I guess the inode is enough; you can do an NFS_I(inode)->fh to get > the fh, but I wouldn't guess you'd want that in the VFS. Bah, here > I go again ... forgive me if that's nonsense.
You wouldn't need to do that anywhere near VFS - all relevant code is inside NFS and yes, there we _are_ allowed to look at ->fh ;-)
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... - 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/
|  |