From mboxrd@z Thu Jan  1 00:00:00 1970
From: Al Viro <viro@ZenIV.linux.org.uk>
Subject: Re: [RFC] __d_path() API change (was Re: [PATCH] Remove use of
 mnt_ns->root and fix a couple of bugs in d_namespace_path)
Date: Tue, 6 Dec 2011 05:20:43 +0000
Message-ID: <20111206052042.GE2203@ZenIV.linux.org.uk>
References: <1323034020-28780-1-git-send-email-john.johansen@canonical.com>
 <20111204221020.GB2203@ZenIV.linux.org.uk>
 <20111205032711.GC2203@ZenIV.linux.org.uk>
 <4EDD7F46.1050907@canonical.com>
 <20111206035838.GD2203@ZenIV.linux.org.uk>
 <201112060441.pB64fLwa005872@www262.sakura.ne.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: linux-fsdevel@vger.kernel.org
To: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Return-path: <linux-fsdevel-owner@vger.kernel.org>
Received: from zeniv.linux.org.uk ([195.92.253.2]:35826 "EHLO
	ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1750831Ab1LFFUo (ORCPT
	<rfc822;linux-fsdevel@vger.kernel.org>);
	Tue, 6 Dec 2011 00:20:44 -0500
Content-Disposition: inline
In-Reply-To: <201112060441.pB64fLwa005872@www262.sakura.ne.jp>
Sender: linux-fsdevel-owner@vger.kernel.org
List-ID: <linux-fsdevel.vger.kernel.org>

On Tue, Dec 06, 2011 at 01:41:21PM +0900, Tetsuo Handa wrote:
> > Cc: stable@vger.kernel.org
> Please add version you meant to apply.

Everything since mid 2010, I'm afraid - that's when apparmor went in and
it had that bug back then.  IOW, 2.6.36 and everything later...

Tomoyo bits will need a backport for stuff older that 3.0 - there had
been changes around 3.0-rc2 or so.

> By the way, why do we need to call like
> 
>   write_seqlock(&rename_lock);
>   error = prepend_path(path, root, &res, &buflen);
>   write_sequnlock(&rename_lock);
> 
> ? I think it would look something like
> 
>   do {
>     seq = read_seqbegin(&rename_lock);
>     error = prepend_path(path, root, &res, &buflen);
>   } while (read_seqretry(&rename_lock, seq));
> 
> because prepend_path() is for reading dentry tree rather than updating ...

I really don't like the idea.  Look what's inside that function; it'll
grab/release ->d_lock on a bunch of dentries, in addition to grabbing
and releasing vfsmount_lock.  We _might_ be able to get away with that
if we just use rcu_read_lock() instead of ->d_lock, but I would very much
like to see the data before doing that kind of change.