On Mon, Mar 30, 2009 at 02:16:49PM +0200, Andi Kleen wrote: > npiggin@xxxxxxx writes: > > > The remaining usages for dcache_lock is to allow atomic, multi-step read-side > > operations over the directory tree by excluding modifications to the tree. > > Also, to walk in the leaf->root direction in the tree where we don't have > > a natural d_lock ordering. This is the hardest bit. > > General thoughts: is there a way to add a self testing infrastructure > to this. e.g. by having more sequence counts per object (only enabled > in the debug case, so it doesn't matter when cache line bounces) and lots of > checks? > > I suppose that would lower the work needed of actually fixing this to > work significantly. Might be a good idea. I'll think about whether it can be done. Note that I *think* the idea is pretty sound, but I'm just not quite sure about checking for parent being deleted when we're walking back up the tree -- d_unhashed() doesn't seem to work because we can encounter unhashed parents by design. We might just need another d_flag... -- 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
