>>>>> " " == Alexander Viro <viro@math.psu.edu> writes:
> Nothing, especially since it will happen automatically when we
> switch to slightly different handling of cwd/root (no
> user-visible changes, will allow union-mounts - basically,
> cleanup of first and last steps of path_walk()).
So what is the plan? I've raised the issue of open(".") on Linux
Fsdevel several times, and ended up getting nowhere. This is the first
time I've heard mention of a planned cleanup of path_walk.
I'll be happy to drop that part of the patch if you can confirm that it
will solve the following problem.
Reminder of the problem
-----------------------
For NFS the current code *is broken* since we don't get called back at
all in path_walk() for the special case of accessing cwd. That has 2
consequences:
- open(".") may succeed even if cwd is know to be a stale dentry.
- The attribute cache, and hence also the data cache, does not get
revalidated. This breaks close-to-open semantics for those who
require it, and leads to silly inconsistencies: typically 'ls -l'
returning gratuitous "file 'blah' does not exist" errors.
Putting cache revalidation in ->open() itself would be a pain: there
is no way of detecting whether or the attributes were checked during
the dcache lookup, so it would mean that we end up duplicating a lot
of cache checks for the non-cwd case.
Using the existing inode->i_op->revalidate() is also not an option,
since it might break other filesystems, and is in any case scheduled
for deletion due to being ill-defined.
If we could use d_revalidate(), then that would be OK as far as I'm
concerned, however this too was deemed unacceptable when raised on
linux-fsdevel.
Cheers,
Trond
-
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 : Wed Jan 23 2002 - 21:00:26 EST