[lkml]   [2003]   [Jun]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [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, 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
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:36    [W:0.019 / U:28.472 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site