From mboxrd@z Thu Jan 1 00:00:00 1970 From: Al Viro Subject: Re: [PATCH] VFS: Fix race with new inode creation Date: Fri, 10 Apr 2009 17:01:39 +0100 Message-ID: <20090410160139.GO26366@ZenIV.linux.org.uk> References: <6601abe90904100831r713031b8u41eb161ab94e0c9b@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: linux-fsdevel@vger.kernel.org To: Curt Wohlgemuth Return-path: Received: from zeniv.linux.org.uk ([195.92.253.2]:55577 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756047AbZDJQBl (ORCPT ); Fri, 10 Apr 2009 12:01:41 -0400 Content-Disposition: inline In-Reply-To: <6601abe90904100831r713031b8u41eb161ab94e0c9b@mail.gmail.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 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.