On Thu, May 29, 2014 at 9:50 PM, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote:
>
> BTW, how serious is the problem with __lockref_is_dead(&dentry->d_lockref)
> with only ->d_parent->d_lock held? From my reading of lib/lockref.c it
> should be safe - we only do lockref_mark_dead() with ->d_parent->d_lock
> held, and it'll provide all the serialization and barriers we need.
>
> If I'm right, we could get rid of DCACHE_DENTRY_KILLED completely
Yeah, I think that would be good. Except I think you should create a
"dentry_is_dead()" helper function that then has that "if you hold the
dentry or parent lock, this is safe" comment, because for lockref in
general you do need to have the lock in the lockref itself. The fact
that dentries have more locking is very much dentry-specific.
But with that, go wild. I'd love to get rid of some of the redundant stuff.
For another example, the
BUG_ON((int)dentry->d_lockref.count > 0);
test makes very little sense any more with lockrefs and the whole dead
marker (that should make sure that it never gets incremented), but
exists due to the direct conversion.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
