From mboxrd@z Thu Jan 1 00:00:00 1970 From: Al Viro Subject: Re: [PATCH 16/21] fs: Protect inode->i_state with the inode->i_lock Date: Sat, 23 Oct 2010 22:40:46 +0100 Message-ID: <20101023214046.GS19804@ZenIV.linux.org.uk> References: <1287622186-1935-1-git-send-email-david@fromorbit.com> <1287622186-1935-17-git-send-email-david@fromorbit.com> <20101022015622.GE19804@ZenIV.linux.org.uk> <20101022031431.GK12506@dastard> <20101022103705.GK19804@ZenIV.linux.org.uk> <20101022114033.GA8859@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: Content-Disposition: inline In-Reply-To: <20101022114033.GA8859@infradead.org> Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Fri, Oct 22, 2010 at 07:40:33AM -0400, Christoph Hellwig wrote: > On Fri, Oct 22, 2010 at 11:37:05AM +0100, Al Viro wrote: > > One more note: IMO sb list lock is better off inside the hash one; when we > > do per-chain hash locks, we'll be better off if we don't have to hold sb > > one over the entire chain search. > > Why would you nest these two at all? [already said off-list, but since the question had been here...] Insertion in hash and into sb list. We *probably* don't care about atomicity of that pair, but in this case we are dealing with two topmost locks of hierarchy that might become independent. That really can be done as a followup.