From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nick Piggin Subject: Re: [patch 09/14] fs: use RCU / seqlock logic for reverse and multi-step operaitons Date: Mon, 30 Mar 2009 14:29:02 +0200 Message-ID: <20090330122902.GG31000@wotan.suse.de> References: <20090329155539.275927173@nick.local0.net> <20090329155749.609663166@nick.local0.net> <874oxbnr2m.fsf@basil.nowhere.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org To: Andi Kleen Return-path: Received: from cantor.suse.de ([195.135.220.2]:45130 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756995AbZC3M3F (ORCPT ); Mon, 30 Mar 2009 08:29:05 -0400 Content-Disposition: inline In-Reply-To: <874oxbnr2m.fsf@basil.nowhere.org> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Mon, Mar 30, 2009 at 02:16:49PM +0200, Andi Kleen wrote: > npiggin@suse.de writes: > > > The remaining usages for dcache_lock is to allow atomic, multi-step read-side > > operations over the directory tree by excluding modifications to the tree. > > Also, to walk in the leaf->root direction in the tree where we don't have > > a natural d_lock ordering. This is the hardest bit. > > General thoughts: is there a way to add a self testing infrastructure > to this. e.g. by having more sequence counts per object (only enabled > in the debug case, so it doesn't matter when cache line bounces) and lots of > checks? > > I suppose that would lower the work needed of actually fixing this to > work significantly. Might be a good idea. I'll think about whether it can be done. Note that I *think* the idea is pretty sound, but I'm just not quite sure about checking for parent being deleted when we're walking back up the tree -- d_unhashed() doesn't seem to work because we can encounter unhashed parents by design. We might just need another d_flag...