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. -Andi -- ak@xxxxxxxxxxxxxxx -- Speaking for myself only. -- 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
