lkml.org 
[lkml]   [2003]   [Jun]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: 2.5.70-bk16: nfs crash
From
>>>>> " " == Dipankar Sarma <dipankar@in.ibm.com> writes:

> 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.

d_lookup() is the only place where someone can pick up an existing
dentry for which they do not already hold a reference.

>> 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().

d_invalidate() does not. d_prune_aliases() does not. d_unhash() does
not.

Down in the per-filesystem code, I know of several locations in the
NFS code that do not. There's one in procfs. I'm sure you can find
more examples in the other filesystems too...

Your argument only holds water if you demand that all callers of
d_drop() should also take the per-dentry lock. AFAICS this is not
being enforced.

Cheers,
Trond
-
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    [W:0.056 / U:0.244 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site