Re: [PATCH] VFS: Fix race with new inode creation

[Nick Piggin <nickpiggin@yahoo.com.au>]

On Wednesday 15 April 2009 02:57:29 Andrew Morton wrote:
> On Fri, 10 Apr 2009 17:01:39 +0100 Al Viro <viro@ZenIV.linux.org.uk> 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@suse.de>
> 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.