On Fri, Apr 17, 2009 at 10:32:19AM +0100, David Woodhouse wrote: > On Fri, 2009-03-20 at 00:34 +0900, hooanon05@xxxxxxxxxxx wrote: > > David Woodhouse: > > > Yes, well spotted. It didn't matter when the buffered readdir() was > > > purely internal to XFS, because it didn't matter there that we called > > > ->lookup() without i_mutex set. But now we're exposing arbitrary file > > > systems to it, we need to make sure we follow the locking rules. > > > > > > I _think_ it's sufficient to make the affected callers of > > > lookup_one_len() lock the parent's i_mutex for themselves before calling > > > it. I'll take a closer look... > > > > If you remember why you discarded the FS_NO_LOOKUP_IN_READDIR flag > > approach, please let me know. URL or something is enough. > > I think someone talked me into doing it in the interest of simplicity, > so we confine the necessary hack into the NFS code alone and _always_ > just use the "safe" version. I can't remember who it was, but I'm > guessing Al or Christoph -- both of whom are CC'd in case they want to > object: Ow... Sorry, I've missed that one. I really don't like flags-based solution ;-/ It's not just filesystem method that want i_mutex there - we have fs/namei.c code suddenly called in different locking conditions now. What were the details of xfs and jffs2 locking problems, just in case if something can be done in that direction short-term? -- 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
