Re: Stale NFS file handles and race conditions...

Steve Mcclure (smcclure@emc.com)
Fri, 27 Aug 1999 09:40:38 -0400


I was thinking something similar, and exactly as your e-mail came in I
was looking at those chunks of code. So, I did a quick test, tried your
patch, and it didn't work (same problem.)

-- Steve

> Urgh. The problem is that 'foo' is being revalidated twice. This means
> that when we pass the following section in
> dir.c:nfs_lookup_revalidate(), we decide to keep the dentry for 'foo'
> since d_count == 2.
>
> /* Filehandle matches? */
> if (memcmp(dentry->d_fsdata, &fhandle, sizeof(struct nfs_fh))) {
> if (!list_empty(&dentry->d_subdirs))
> shrink_dcache_parent(dentry);
> if (dentry->d_count < 2)
> goto out_bad;
> }
>
> At the time (linux-2.2.4), the protection against d_count < 2 was
> necessary because of a bug in the linux NFS servers which caused
> filehandles to change over the course of the lifetime of the file (I
> believe there was a case of timestamping). At the time, the 'stale
> inode' verification code in nfs_fhget() couldn't handle unhashed
> dentries, which meant that open files could suddenly find that their
> filehandle was set to zero.
>
> Since then, the stale inode code has changed (and hopefully
> improved) so as to be able to handle unhashed dentries. Perhaps it is
> better to relax the above code, and to trust nfs_fhget to get things
> right?
>
>
> Cheers,
> Trond

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/