[Lustre-discuss] Looping in __d_lookup

[Andreas Dilger]

On Jun 04, 2008  00:19 +0200, Jakob Goldbach wrote:
> > On Wed, 2008-05-21 at 21:05 +0200, Jakob Goldbach wrote:
> > > 
> > > So the lockup in __d_lookup may just relate to newer patchless clients. 
> 
> I got rid of my dcache chain corruption by adding patch below and
> exporting _d_rehash from kernel (offcourse, no longer patchless). 
> 
> Could this fix a race in patchless code ? 
> 
> /Jakob
> 
> p.s: A kind soul came up with this. Im not a kernel hacker. 
> 
> 
> --- ./lustre/llite/dcache.c.xxx	2007-09-27 16:04:08.000000000 +0400
> +++ ./lustre/llite/dcache.c	2008-05-29 11:53:07.000000000 +0400
> @@ -470,8 +470,8 @@ revalidate_finish:
>          spin_lock(&dcache_lock);
>          lock_dentry(de);
>          __d_drop(de);
> +        _d_rehash(de);
>          unlock_dentry(de);
> -        __d_rehash(de, 0);
>          spin_unlock(&dcache_lock);

It seems (with 2.6.18-RHEL5 at least) that it is possible to implement
_d_rehash() without any exported kernel functions:

static inline void _d_rehash(struct dentry *dentry)
{
	dentry->d_flags &= ~DCACHE_UNHASHED;
	hlist_add_head_rcu(&dentry->d_hash,
			   d_hash(entry->d_parent, entry->d_name.hash);
}

This should be added to lustre_patchless_compat.h.  We have an existing
function "d_rehash_cond(dentry, lock)" which is only ever called from
Lustre when we don't want to lock the dcache_lock, but the above usage
is racy.  This should be replaced with _d_rehash() as above for patchless
clients (where d_rehash_cond() is never implemented).

Can you please file a bug with the original details, so that this gets
fixed in the next release.

Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.