On Wed, Mar 28, 2012 at 11:45 PM, Myklebust, Trond <Trond.Myklebust@xxxxxxxxxx> wrote: > On Wed, 2012-03-28 at 22:24 +0200, Miklos Szeredi wrote: >> From: Miklos Szeredi <mszeredi@xxxxxxx> >> >> NFSv4 can't do reliable opens in d_revalidate, since it cannot know whether a >> mount needs to be followed or not. It does check d_mountpoint() on the dentry, >> which can result in a weird error if the VFS found that the mount does not in >> fact need to be followed, e.g.: >> >> # mount --bind /mnt/nfs /mnt/nfs-clone >> # echo something > /mnt/nfs/tmp/bar >> # echo x > /tmp/file >> # mount --bind /tmp/file /mnt/nfs-clone/tmp/bar >> # cat /mnt/nfs/tmp/bar >> cat: /mnt/nfs/tmp/bar: Not a directory >> >> Which should, by any sane filesystem, result in "something" being printed. >> >> So instead do the open in f_op->open() and in the unlikely case that the cached >> dentry turned out to be invalid, drop the dentry and return ESTALE to let the >> VFS retry. > > > Just one comment. Would it now make sense for NFSv4 to just skip > ->d_revalidate() if LOOKUP_OPEN is set, and LOOKUP_EXCL is not set? We > will in any case be doing a revalidation in nfs4_file_open. And dentry is positive and regular. Which is basically what nfs4_lookup_revalidate() does check at the moment. One question is whether this can be done without dropping out of RCU mode, which might be a real performance win. I'm not sure about dereferencing inode->i_mode. AFAICS it should be fine, considering that destruction of the inode will leave the mode bits untouched, but... Thanks, Miklos -- 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
