From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter Zijlstra Subject: Re: [PATCH 00/46] rcu-walk and dcache scaling Date: Tue, 07 Dec 2010 16:49:34 +0100 Message-ID: <1291736974.2032.665.camel@laptop> References: <20101207112555.GE16103@dastard> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT Cc: Dave Chinner , Nick Piggin , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org To: Nick Piggin Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Wed, 2010-12-08 at 02:24 +1100, Nick Piggin wrote: > > repeat: > spin_lock(&parent->d_lock); > spin_lock_nested(&dentry->d_lock, DENTRY_D_LOCK_NESTED); > /* do stuff */ > spin_unlock(&parent->d_lock); > spin_release(&dentry->d_lock.dep_map, 1, _RET_IP_); > parent = dentry; > spin_acquire(&this_parent->d_lock.dep_map, 0, 1, _RET_IP_); > goto repeat; shouldn't that be s/this_parent/parent/ ? So what you're trying to do is: A -> B -> C -> ... lock A lock B, nested unlock A flip B from nested to top lock C, nested unlock B flip C from nested to top lock ... Anyway, the way to write that is something like: lock_set_subclass(&detry->d_lock.dep_map, 0, _RET_IP_); Which will reset the subclass of the held lock from DENTRY_D_LOCK_NESTED to 0. This is also used in double_unlock_balance(), we go into double_lock_balance() with this_rq locked and want to lock busiest, because of the lock ordering we might need to unlock this_rq and lock busiest first, at which point this_rq is nested. On unlock we thus need to map this_rq back to subclass 0 (which it had before double_lock_balance(), because otherwise subsequent lock operations will be done against the subclass and confuse things.