From mboxrd@z Thu Jan  1 00:00:00 1970
From: Tim Pepper <lnxninja@linux.vnet.ibm.com>
Subject: Re: [patch 16/28] fs: Use rename lock and RCU for multi-step operations
Date: Fri, 19 Nov 2010 11:42:21 -0800
Message-ID: <AANLkTin-c3hJ64ytgOp2Yx0SeJE7v6vQ7GRGds09YMQx@mail.gmail.com>
References: <20101116140900.039761100@kernel.dk>
	<20101116142029.721937333@kernel.dk>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: QUOTED-PRINTABLE
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
To: Nick Piggin <npiggin@kernel.dk>
Return-path: <linux-kernel-owner@vger.kernel.org>
In-Reply-To: <20101116142029.721937333@kernel.dk>
Sender: linux-kernel-owner@vger.kernel.org
List-Id: linux-fsdevel.vger.kernel.org

On Tue, Nov 16, 2010 at 6:09 AM, Nick Piggin <npiggin@kernel.dk> wrote:

> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* might go back up the wrong parent if=
 we have had a rename
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* or deletion */
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (this_parent !=3D child->d_parent ||
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 read_se=
qretry(&rename_lock, seq)) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 spin_unlock(&this_paren=
t->d_lock);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 spin_unlock(&dcache_loc=
k);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 rcu_read_unlock();
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto rename_retry;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 }
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 rcu_read_unlock();
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 next =3D child->d_u.d_child.next;

Again there are something like three insertions of this check.  Right
now it arguably makes sense to have everything explicitly clear inline
at every instance of the code for review, but eventually it might be
more readable if these became something like:

if (rename_happened(...))
        goto rename_retry;

(accounting for the change in patch 19 of course)