lkml.org 
[lkml]   [2003]   [Jun]   [13]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
DateFri, 13 Jun 2003 11:20:01 +0530
FromDipankar Sarma <>
SubjectRe: 2.5.70-bk16: nfs crash
On Thu, Jun 12, 2003 at 10:24:16PM -0700, Trond Myklebust wrote:
> Wrong. Look at the VFS code. In all cases the test is of the form.
> 
>     spin_lock(&dcache_lock);
>     /* Are we the sole users of this dentry */
>     if (atomic_read(&dentry->d_count) == 1) {
>        /* Yes - do some operation */
>     }
> 
> 
> Knowing that d_lookup() can *increase* d_count is not a plus here. The
> whole idea is to have a test for sole use.

Well, d_lookup() isn't the only place that does a dget() without
holding dcache_lock. There are *many* places where dget() is
done without holding dcache_lock. That didn't seem to be a
requirement in the pre-RCU dcache model.

> 
> In most cases, the "do some operation" above is
> 
> 	d_drop(dentry);
> 

I don't think that would work in pre or post-RCU dcache.

> in order (for instance) to ensure that nobody else can look up this
> dentry while we're working on it (e.g. rename or unlink,...).

rename, unlink etc. hold the per-dentry lock, so they are protected
against lockfree d_lookup().

> 
> Your d_lookup() screws the above example of code which you can find in
> any number of VFS functions. dput(), d_delete(), d_invalidate(),
> d_prune_aliases(), prune_dcache(), shrink_dcache_sb() are but a few
> functions that rely on the above code snippet working to keep
> d_lookup() from intruding.

Those routines hold the per-dentry lock as required and that protects
them from intruding lockfree d_lookup().

Thanks
Dipankar
-
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/

\
 
 \ /
  Last update: 2005-03-22 13:36    [from the cache]
©2003-2008