Re: NFS regression in 2.6

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

>>>>> " " == Andries Brouwer <aebr@win.tue.nl> writes:

     > I don't think it will. My analysis of yesterday night was:
     > - no silly rename is done
     > - this is because d_count equals 1
     > - this is because we have two different dentries for the same
     >   file
     > - this is caused by the fragment

     >         /* If we're doing an exclusive create, optimize away
     >         the lookup */ if (nfs_is_exclusive_create(dir, nd))
     >                 return NULL;

     > in nfs/dir.c.  Do you agree?

No... The above snippet just short-circuits the process of doing an
RPC call in order to look the file up on the *server*. Doing such a
lookup would be wrong since it can race with a file creation on
another NFS client.
IOW the result of the above 2 lines should be the immediate creation
of a negative dentry (i.e. one without an inode) that open_namei() can
pass on to vfs_create().

When we get to the unlink() call, we shouldn't be hitting nfs_lookup()
at all unless something somewhere is causing this first dentry to be
permanently dropped out of the dcache.

In short the scenario should be that

  - mkstemp() does an open(O_EXCL) -> nfs_lookup() creates hashed
    negative dentry -> nfs_create() then does an O_EXCL call to the
    server and instantiates the dentry.

  - unlink() walks the pathname -> finds the existing dentry using
    cached_lookup() and only calls down to nfs_lookup_revalidate().

Cheers,
  Trond