From mboxrd@z Thu Jan  1 00:00:00 1970
From: Daniel J Blueman <daniel.blueman@gmail.com>
Subject: Re: [2.6.39-rc1] LTP hitting max (8) nested links...
Date: Mon, 4 Apr 2011 22:56:11 +0800
Message-ID: <BANLkTikA8QXXCMPnigP6_cDJNpt2EWMagA@mail.gmail.com>
References: <BANLkTi=pS8Wk9Ymtj=DeVqfgqBsbTXDHZA@mail.gmail.com>
	<BANLkTi=Mu70wYSM0sVRWZnQzTPBOvqt6xg@mail.gmail.com>
	<131751.1301921295@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: QUOTED-PRINTABLE
To: Valdis.Kletnieks@vt.edu, Nick Piggin <npiggin@kernel.dk>,
	Linux Kernel <linux-kernel@vger.kernel.org>,
	linux-fsdevel@vger.kernel.org
Return-path: <linux-kernel-owner@vger.kernel.org>
In-Reply-To: <131751.1301921295@localhost>
Sender: linux-kernel-owner@vger.kernel.org
List-Id: linux-fsdevel.vger.kernel.org

On 4 April 2011 20:48,  <Valdis.Kletnieks@vt.edu> wrote:
> On Mon, 04 Apr 2011 11:19:08 +0800, Daniel J Blueman said:
>
>> Re-reading everything, nested here is actually recursively nested, n=
ot
>> consecutively nested, so will never succeed, so we expect this from
>> the LTP test.
>
> We expect the LTP test to be handed an error, I suspect. =A0The LTP t=
est
> probably shouldn't be able to provoke a BUG_ON.

In fact, since userspace does correctly return ELOOP [1], and I can't
reproduce it with 2.6.37, it does looks like a race in the RCU VFS
lookup, so adding Nick in the loop.

--- [1]

$ ln -s foo bar && ln -s bar foo
$ strace -e mkdir mkdir foo/a
mkdir("foo/a", 0777)                    =3D -1 ELOOP (Too many levels o=
f
symbolic links)
mkdir: cannot create directory `foo/a': Too many levels of symbolic lin=
ks
--=20
Daniel J Blueman