From mboxrd@z Thu Jan 1 00:00:00 1970 From: Al Viro Subject: Re: ->d_lock FUBAR (was Re: Linux 3.0-rc6) Date: Wed, 13 Jul 2011 04:22:39 +0100 Message-ID: <20110713032239.GN11013@ZenIV.linux.org.uk> References: <20110711060315.GI11013@ZenIV.linux.org.uk> <20110712234806.GJ11013@ZenIV.linux.org.uk> <20110713005634.GK11013@ZenIV.linux.org.uk> <20110713013936.GL11013@ZenIV.linux.org.uk> <20110713025918.GM11013@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]:58499 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932358Ab1GMDWm (ORCPT ); Tue, 12 Jul 2011 23:22:42 -0400 Content-Disposition: inline In-Reply-To: <20110713025918.GM11013@ZenIV.linux.org.uk> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Wed, Jul 13, 2011 at 03:59:18AM +0100, Al Viro wrote: > I'm not sure how much do we care about stability of x->d_parent when > x->d_lock is held. ->d_compare() is the most obvious potential area > of trouble in that respect, but there might be more. Oh, and another fun area is per-chain locks, of course ;-/ Look at __d_drop(); reengineering the callers of d_drop() to make sure that fscker's parent stays stable would be very painful and turning that into loop-based variant is going to be interesting. Doable, but not fun...