From mboxrd@z Thu Jan  1 00:00:00 1970
From: Nick Piggin <nickpiggin@yahoo.com.au>
Subject: Re: [PATCH] VFS: Fix race with new inode creation
Date: Wed, 15 Apr 2009 03:30:43 +1000
Message-ID: <200904150330.44212.nickpiggin@yahoo.com.au>
References: <6601abe90904100831r713031b8u41eb161ab94e0c9b@mail.gmail.com> <20090410160139.GO26366@ZenIV.linux.org.uk> <20090414095729.bd407689.akpm@linux-foundation.org>
Mime-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Cc: Al Viro <viro@zeniv.linux.org.uk>,
	Curt Wohlgemuth <curtw@google.com>,
	linux-fsdevel@vger.kernel.org
To: Andrew Morton <akpm@linux-foundation.org>
Return-path: <linux-fsdevel-owner@vger.kernel.org>
Received: from smtp103.mail.mud.yahoo.com ([209.191.85.213]:44869 "HELO
	smtp103.mail.mud.yahoo.com" rhost-flags-OK-OK-OK-OK)
	by vger.kernel.org with SMTP id S1758166AbZDNRbI (ORCPT
	<rfc822;linux-fsdevel@vger.kernel.org>);
	Tue, 14 Apr 2009 13:31:08 -0400
In-Reply-To: <20090414095729.bd407689.akpm@linux-foundation.org>
Content-Disposition: inline
Sender: linux-fsdevel-owner@vger.kernel.org
List-ID: <linux-fsdevel.vger.kernel.org>

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.