On Tue, 2011-01-11 at 20:06 -0800, Linus Torvalds wrote: > On Tue, Jan 11, 2011 at 7:59 PM, Ian Kent <raven@xxxxxxxxxx> wrote: > > > > Isn't the parent i_mutex held during mkdir()? > > Yes, but a lookup that hits in the dentry cache won't actually take > the parent mutex. > > So as far as I can tell, doing the "d_add()" before setting d_op can > result in another CPU coming in and seeing the newly added dentry > before d_op has actually been initialized. Exactly because it will do > the dentry lookup without holding any mutex. > > Of course, it's a very small window, so it probably doesn't matter in practice. > > >> 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. > > > > Yeah, a hangover from changes done over time. > > Not setting the dentry op in ->lookup() should fix this. > > Alex, care to test just removing the d_set_d_op() call from autofs4_lookup()? > > (That code is a bit scary, though - it explicitly makes it a negative > dentry with a d_instantiate(dentry, NULL), and then hides the inode > information away separately. Scary scary) Yeah, but the expire to mount races with autofs are difficult to handle and this approach has worked well under heavy stress testing. It's true that this would almost certainly be bad for a file system that supported a full range of functionality but that's not so for autofs. > > 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 -- 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
