From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nick Piggin Subject: Re: [PATCH 04/17] fs: icache lock i_state Date: Sat, 16 Oct 2010 18:54:21 +1100 Message-ID: <20101016075421.GB19147@amd> References: <1285762729-17928-1-git-send-email-david@fromorbit.com> <1285762729-17928-5-git-send-email-david@fromorbit.com> <20101001055433.GC32349@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Dave Chinner , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org To: Christoph Hellwig Return-path: Received: from ipmail06.adl2.internode.on.net ([150.101.137.129]:1494 "EHLO ipmail06.adl2.internode.on.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753173Ab0JPHyX (ORCPT ); Sat, 16 Oct 2010 03:54:23 -0400 Content-Disposition: inline In-Reply-To: <20101001055433.GC32349@infradead.org> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Fri, Oct 01, 2010 at 01:54:33AM -0400, Christoph Hellwig wrote: > > + spin_lock(&inode->i_lock); > > + if (inode->i_state & (I_FREEING|I_WILL_FREE|I_NEW) > > + || inode->i_mapping->nrpages == 0) { > > > This is some pretty strange formatting. > > if ((inode->i_state & (I_FREEING|I_WILL_FREE|I_NEW)) || > inode->i_mapping->nrpages == 0) { > > would be more standard. > > > list_for_each_entry(inode, &sb->s_inodes, i_sb_list) { > > struct address_space *mapping; > > > > - if (inode->i_state & (I_FREEING|I_WILL_FREE|I_NEW)) > > - continue; > > mapping = inode->i_mapping; > > if (mapping->nrpages == 0) > > continue; > > + spin_lock(&inode->i_lock); > > + if (inode->i_state & (I_FREEING|I_WILL_FREE|I_NEW)) { > > + spin_unlock(&inode->i_lock); > > + continue; > > + } > > Can we access the mapping safely when the inode isn't actually fully > setup? Even if we can I'd rather not introduce this change hidden > inside an unrelated patch. Good point, fixed.