From mboxrd@z Thu Jan 1 00:00:00 1970 From: Al Viro Subject: ->d_lock FUBAR (was Re: Linux 3.0-rc6) Date: Wed, 13 Jul 2011 00:48:07 +0100 Message-ID: <20110712234806.GJ11013@ZenIV.linux.org.uk> References: <20110711060315.GI11013@ZenIV.linux.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: linux-fsdevel@vger.kernel.org, npiggin@kernel.dk To: Linus Torvalds Return-path: Received: from zeniv.linux.org.uk ([195.92.253.2]:46855 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751203Ab1GLXsJ (ORCPT ); Tue, 12 Jul 2011 19:48:09 -0400 Content-Disposition: inline In-Reply-To: <20110711060315.GI11013@ZenIV.linux.org.uk> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Mon, Jul 11, 2011 at 07:03:15AM +0100, Al Viro wrote: > * If there is an ancestor relationship: > * dentry->d_parent->...->d_parent->d_lock > * ... > * dentry->d_parent->d_lock > * dentry->d_lock > * > * If no ancestor relationship: > * if (dentry1 < dentry2) > * dentry1->d_lock > * dentry2->d_lock > > is no good: suppose A is ancestor of B and C is unrelated to either. > With B sitting at lower address than C and A at higher one. We have > A before B, since it's an ancestor; C before A since they are unrelated > and addresses compare that way; B before C (ditto). Loops in lock > ordering are generally bad; we _might_ get away with that in this case > since we serialize d_move() callers to hell and back, but... But it's not enough. Look: getting from rcu pathwalk to normal one involves * grabbing d_lock on parent * grabbing d_lock on child * checking that child hadn't been moved elsewhere in the meanwhile All flakiness of the locking "order" aside, here we simply lock two dentries that might be nowhere near each other by now. Hell, by that point the parent might've been moved under (what used to be) child. Or it might have address greater than that of child and be not an ancestor anymore. Note that no i_mutex, etc. is held at that point, so there's no external serialization to save our arses...