Re: 2.5.70-bk16: nfs crash

[Trond Myklebust <trond.myklebust@fys.uio.no>]

>>>>> " " == 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