From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dave Chinner Subject: Re: [patch 29/52] fs: icache lock i_count Date: Wed, 30 Jun 2010 17:27:02 +1000 Message-ID: <20100630072702.GF24712@dastard> References: <20100624030212.676457061@suse.de> <20100624030730.245992858@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, John Stultz , Frank Mayhar To: npiggin@suse.de Return-path: Content-Disposition: inline In-Reply-To: <20100624030730.245992858@suse.de> Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Thu, Jun 24, 2010 at 01:02:41PM +1000, npiggin@suse.de wrote: > Protect inode->i_count with i_lock, rather than having it atomic. > Next step should also be to move things together (eg. the refcount increment > into d_instantiate, which will remove a lock/unlock cycle on i_lock). ..... > Index: linux-2.6/fs/inode.c > =================================================================== > --- linux-2.6.orig/fs/inode.c > +++ linux-2.6/fs/inode.c > @@ -33,14 +33,13 @@ > * inode_hash_lock protects: > * inode hash table, i_hash > * inode->i_lock protects: > - * i_state > + * i_state, i_count > * > * Ordering: > * inode_lock > * sb_inode_list_lock > * inode->i_lock > - * inode_lock > - * inode_hash_lock > + * inode_hash_lock > */ I thought that the rule governing the use of inode->i_lock was that it can be used anywhere as long as it is the innermost lock. Hmmm, no references in the code or documentation. Google gives a pretty good reference: http://www.mail-archive.com/linux-ext4@vger.kernel.org/msg02584.html Perhaps a different/new lock needs to be used here? Cheers, Dave. -- Dave Chinner david@fromorbit.com