Re: 2.5.70-bk16: nfs crash

From: Trond Myklebust (
Date: Fri Jun 13 2003 - 00:24:16 EST

>>>>> " " == Dipankar Sarma <> 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.

    /* 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


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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

This archive was generated by hypermail 2b29 : Sun Jun 15 2003 - 22:00:35 EST