Messages in this thread | | | Date | Thu, 12 Jun 2003 22:24:16 -0700 | Subject | Re: 2.5.70-bk16: nfs crash | From | Trond Myklebust <> |
| |
>>>>> " " == Dipankar Sarma <dipankar@in.ibm.com> writes:
>> Look at all those functions that take dcache_lock, and then >> test >> dentry-> d_count. Unless I'm missing something here, your >> d_lookup() clearly has them all screwed, no?
> Not necessarily. One example is the fact that d_lookup() can > only increase d_count. Besides, dput() decrements d_count > without dcache_lock, so I am not sure holding dcache_lock > during d_count test buys you much.
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.
In most cases, the "do some operation" above is
d_drop(dentry);
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,...).
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.
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/
| |