On Tue, Jul 05, 2016 at 12:33:09PM -0400, Oleg Drokin wrote: > This also makes me question the whole thing some more. We are definitely in lookup > when this hits, so the dentry is already new, yet it does not check off as > d_in_lookup(). That also means that by skipping the ll_splice_alias we are failing > to hash it and that causing needless lookups later? > Looking some back into the history of commits, d_in_lookup() is to tell us > that we are in the middle of lookup. How can we be in the middle of lookup > path then and not have this set on a dentry? We know dentry was not > substituted with anything here because we did not call into ll_split_alias(). > So what's going on then? Lookup in directory locked exclusive, that's what... In unlink(), in your testcase. And yes, this piece of 1/3 is incorrect; what I do not understand is the logics of what you are doing with dcache in ll_splice_alias() and in its caller ;-/ -- 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
