Re: [PATCH 2.5.3-pre1] Fix NFS dentry lookup behaviour

[Trond Myklebust <trond.myklebust@fys.uio.no>]

>>>>> " " == 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