On Wednesday 15 April 2009 02:57:29 Andrew Morton wrote: > On Fri, 10 Apr 2009 17:01:39 +0100 Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote: > > > On Fri, Apr 10, 2009 at 08:31:40AM -0700, Curt Wohlgemuth wrote: > > > This patch fixes a race between a task creating a new inode, and one writing > > > that same new, dirty inode out to disk. > > > > > > We found this using a particular workload (fsstress) along with other > > > ancillary processes running on the same machine. The symptom is one or more > > > hung unkillable (uniterruptible sleep) tasks that try to operate on this new > > > inode. > > > > > > The original comment block is wrong. Since the inode gets marked dirty > > > after it's created, but before its I_LOCK bit is cleared, there _can_ be > > > somebody else doing something with this inode -- e.g., a writeback task > > > (in our case, __sync_single_inode()). > > > > Um... I'd say that the real bug in there is that we shouldn't *get* to > > __sync_single_inode() until I_NEW/I_LOCK are removed. > > I suspect Nick recently fixed this? > > > commit aabb8fdb41128705fd1627f56fdd571e45fdbcdb > Author: Nick Piggin <npiggin@xxxxxxx> > Date: Wed Mar 11 13:17:36 2009 -0700 > > fs: avoid I_NEW inodes You probably meant this one: 7ef0d7377cb287e08f3ae94cebc919448e1f5dff ? Yes, I think that should fix it. The "fs: avoid I_NEW inodes" patch I don't think we actually found a bug which it fixes, but Jan and I both thought it is less fragile to just avoid I_NEW inodes unless explicitly required for some reason. -- 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
