From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dave Chinner Subject: Re: [PATCH 07/18] fs: rework icount to be a locked variable Date: Sat, 16 Oct 2010 11:20:43 +1100 Message-ID: <20101016002043.GM4681@dastard> References: <1286928961-15157-1-git-send-email-david@fromorbit.com> <1286928961-15157-8-git-send-email-david@fromorbit.com> <20101013113643.GD19456@infradead.org> <20101016001533.GL4681@dastard> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org To: Christoph Hellwig Return-path: Content-Disposition: inline In-Reply-To: <20101016001533.GL4681@dastard> Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Sat, Oct 16, 2010 at 11:15:33AM +1100, Dave Chinner wrote: > On Wed, Oct 13, 2010 at 07:36:43AM -0400, Christoph Hellwig wrote: > > > - atomic_inc(&inode->i_count); > > > + spin_lock(&inode->i_lock); > > > + inode->i_ref++; > > > + spin_unlock(&inode->i_lock); > > > > Why isn't this using iref? > > > > > + spin_lock(&inode->i_lock); > > > + inode->i_ref++; > > > + spin_unlock(&inode->i_lock); > > > > Same here and in a couple of others. > > > > Hmm, I guess because the i_lock later covers other things around. > > But it still looks a bit weird. > > Ok, I've changed them to iref() calls and convert them to open > coding later on when necessary. Oh, NAK that - hit send too soon. I forgot - they're are done that way because they are under the inode_lock, and iref(), at this point in the series, takes the inode_lock. So while it looks weird, it has to stay that way otherwise it deadlocks..... Cheers, Dave. -- Dave Chinner david@fromorbit.com