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)

[Al Viro <viro@ZenIV.linux.org.uk>]

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.