Re: NFS regression in 2.6

[Andries Brouwer <aebr@win.tue.nl>]

On Wed, Aug 20, 2003 at 11:43:04AM -0700, Trond Myklebust wrote:
> >>>>> " " == 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().

It should be. But it isnt. I propose the following patch
(with whitespace damage):

diff -u --recursive --new-file -X /linux/dontdiff a/fs/nfs/dir.c b/fs/nfs/dir.c
--- a/fs/nfs/dir.c      Fri Jul 11 00:35:26 2003
+++ b/fs/nfs/dir.c      Wed Aug 20 22:38:42 2003
@@ -671,8 +671,10 @@
        dentry->d_op = &nfs_dentry_operations;
 
        /* If we're doing an exclusive create, optimize away the lookup */
-       if (nfs_is_exclusive_create(dir, nd))
+       if (nfs_is_exclusive_create(dir, nd)) {
+               d_add(dentry, NULL);
                return NULL;
+       }
 
        lock_kernel();
        error = nfs_cached_lookup(dir, dentry, &fhandle, &fattr);

Andries