From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dave Chinner Subject: Re: [PATCH 17/19] fs: Reduce inode I_FREEING and factor inode disposal Date: Sun, 17 Oct 2010 15:13:13 +1100 Message-ID: <20101017041313.GJ32255@dastard> References: <1287216853-17634-1-git-send-email-david@fromorbit.com> <1287216853-17634-18-git-send-email-david@fromorbit.com> <20101017013047.GA4394@infradead.org> <20101017024923.GA6453@amd> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Christoph Hellwig , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org To: Nick Piggin Return-path: Content-Disposition: inline In-Reply-To: <20101017024923.GA6453@amd> Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Sun, Oct 17, 2010 at 01:49:23PM +1100, Nick Piggin wrote: > On Sat, Oct 16, 2010 at 09:30:47PM -0400, Christoph Hellwig wrote: > > > * inode->i_lock is *always* the innermost lock. > > > * > > > + * inode->i_lock is *always* the innermost lock. > > > + * > > > > No need to repeat, we got it.. > > Except that I didn't see where you fixed all the places where it is > *not* the innermost lock. Like for example places that take dcache_lock > inside i_lock. I can't find any code outside of ceph where the dcache_lock is used within 200 lines of code of the inode->i_lock. The ceph code is not nesting them, though. And AFAICT, the i_lock is not used at all in the dentry code. So I must be missing something if this is occurring - can you point out where this lock ordering is occurring in the mainline code? Cheers, Dave. -- Dave Chinner david@fromorbit.com