From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter Zijlstra Subject: Re: [patch 16/52] fs: dcache RCU for multi-step operaitons Date: Thu, 24 Jun 2010 09:58:10 +0200 Message-ID: <1277366290.1875.891.camel@laptop> References: <20100624030212.676457061@suse.de> <20100624030728.129875799@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, John Stultz , Frank Mayhar To: npiggin@suse.de Return-path: Received: from bombadil.infradead.org ([18.85.46.34]:37692 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754493Ab0FXH6O convert rfc822-to-8bit (ORCPT ); Thu, 24 Jun 2010 03:58:14 -0400 In-Reply-To: <20100624030728.129875799@suse.de> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Thu, 2010-06-24 at 13:02 +1000, npiggin@suse.de wrote: > plain text document attachment (fs-dcache_lock-multi-step.patch) > 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 could be accomplished by taking every d_lock, but this would mean a > huge number of locks and actually gets very tricky. > > Solve this instead by using the rename seqlock for multi-step read-side > operations. Insert operations are not serialised. Delete operations are > tricky when walking up the directory our parent might have been deleted > when dropping locks so also need to check and retry for that. > > XXX: hmm, we could of course just take the rename lock if there is any worry > about livelock. Most of these are slow paths. Ah, does this address John's issue?