Hello!
On Jan 17, 2012, at 3:26 AM, Lai Siyao wrote:
> Are you referring to ll_lookup_it_finish() that flag negative dentry
> DCACHE_LUSTRE_INVALID and hash/unhash it immediately if client doesn't have
> UDATE lock? Looks like such dentry is skipped during link path walk as
> ll_dcompare checks DCACHE_LUSTRE_INVALID. Or am I looking at wrong place?
> Normally lustre client doesn't fetch any child lock for lookup(IT_OPEN), but
> a child dentry will be inserted into hash, however this dentry is marked
> INVALID, and it will be freed after file->release(), that means, no other
> processes will use the dentry (in this case other processes will create
> another dentry for this file and add to hash too). So Oleg means a dentry may
> be inserted into hash without LOOKUP lock, but this dentry won't be used by
> others, so it will not cause the race you mentioned.
Actually that was not always the case, the check in d_compare was added a few
years later and before then it was perfectly possible
to find invalid dentries and that's why we had this d_revalidate check hitting.
Bye,
Oleg
--
Oleg Drokin
Senior Software Engineer
Whamcloud, Inc.
_______________________________________________
Lustre-discuss mailing list
Lustre-discuss@lists.lustre.org
http://lists.lustre.org/mailman/listinfo/lustre-discuss
