On 05/07/2010 06:34 PM, Neil Brown wrote:
On Thu, 06 May 2010 09:58:31 -0400 Trond Myklebust<trond.myklebust@xxxxxxxxxx> wrote:
diff --git a/fs/namei.c b/fs/namei.c
index a7dce91..256ae13 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -719,7 +719,11 @@ static int do_lookup(struct nameidata *nd, struct qstr *name,
done:
path->mnt = mnt;
path->dentry = dentry;
- __follow_mount(path);
+ if (__follow_mount(path)&&
+ (path->mnt->mnt_sb->s_type->fs_flags& FS_REVAL_DOT)) {
+ if (!path->dentry->d_op->d_revalidate(path->dentry, nd))
+ return -ESTALE;
Won't this prevent you from ever being able to unmount the stale
filesystem?
Good point - I think you are right.
It seems to me that ->d_revalidate is being used for two distinct, though
related, tasks.
One is to revalidate the dentry - make sure the name still refers to the same
inode. The other is to revalidate the inode - make sure the cached
attributes are still valid. In NFS (v3 and v4 at least) these are both
performed by one call so it makes some sense to combine them. But from the
VFS perspective I would have thought they were quite separate.
nfs_lookup_revalidate sometimes does a GETATTR, and sometimes does a LOOKUP,
depending to some extent on the 'intent' in the nameidata. I find this makes
it a bit hard to follow what is really happening, or how d_revalidate should
really be used.
Maybe we should just ignore the return value above. Or maybe d_revalidate
should never do a GETATTR - that should be done by ->open ??
Confused :-(
The reason for this arrangement is that by the time ->open is called,
it's too late to return ESTALE. During the path walk, there is still an
opportunity to renew the mapping between dentry and inode, should the
cached value of that mapping be stale.
--
chuck[dot]lever[at]oracle[dot]com
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
