Messages in this thread | | | Date | Thu, 12 Jun 2003 23:13:31 -0700 | Subject | Re: 2.5.70-bk16: nfs crash | From | Trond Myklebust <> |
| |
>>>>> " " == 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/
| |