On Wed, Jan 12, 2011 at 5:13 AM, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > [ Added Ian to cc - the BUG_ON() in d_set_d_op() triggers on autofs4, > see lkml thread for more details if you care ] > > On Tue, Jan 11, 2011 at 9:57 AM, Alex Elder <aelder@xxxxxxx> wrote: >> >> Looking at it quickly, I don't think that would matter for >> the case at hand. I.e., that might be safer but it doesn't >> address the fact that these fields are getting initialized >> multiple times. > > You're right - without looking closer or thinking about it any more, I > was thinking mkdir etc would create the new dentry, but it can easily > be a pre-existing negative one. So it's not like mkdir is always going > to be something new that can just be initialized. > > So yeah, no race or anything like that required - just regular acceses. > > That said, if we make sure that the d_op gets cleared (or the dentry > dropped) when something turns negative, and a negative lookup never > sets d_op, it should all basically work. > > Can you figure out the exact sequence that causes this? Is it enough > to just mount something once? Doh, sorry I probably didn't re-test autofs4 since putting that BUG_ON in there. Now it's trivial to revert the d_set_d_op function to the same raciness that was "allowed" before (simply by resetting the d_flags bits). There is no new fundamental race that the patch introduced there... But I think it is much cleaner to just fix up all filesystems, and will potentially close obscure races. Often the best way is to just set the same d_ops for negative and positive dentries, and have the operations handle both cases. Ian? -- 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
