From mboxrd@z Thu Jan  1 00:00:00 1970
From: Al Viro <viro@ZenIV.linux.org.uk>
Subject: Re: [GIT PULL] vfs.git
Date: Thu, 11 Dec 2014 18:34:56 +0000
Message-ID: <20141211183456.GY22149@ZenIV.linux.org.uk>
References: <20141210191302.GO22149@ZenIV.linux.org.uk>
 <CAELBmZDLTOskhHaZEMOPA8n9VgAcr0cJvqYjx=YADpx_=mYQcw@mail.gmail.com>
 <20141211180624.GX22149@ZenIV.linux.org.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	LKML <linux-kernel@vger.kernel.org>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>
To: Miklos Szeredi <miklos@szeredi.hu>
Return-path: <linux-kernel-owner@vger.kernel.org>
Content-Disposition: inline
In-Reply-To: <20141211180624.GX22149@ZenIV.linux.org.uk>
Sender: linux-kernel-owner@vger.kernel.org
List-Id: linux-fsdevel.vger.kernel.org

On Thu, Dec 11, 2014 at 06:06:24PM +0000, Al Viro wrote:

> Check the remaining users of ->f_path.dentry.  I agree that they ought to
> be encapsulated into a sane set of helpers - raw access to ->f_path in
> filesystems is asking for serious trouble.  And we have very few such places
> remaining.

Sloppy writing: insert "with the exception of filesystems that are not
going to be suitable for any form of stacking" - there _is_ a bunch of
debugfs, configfs, kernfs places using that.  They'd also better be
taken care of, but it's an independent story; for overlayfs/unionmount/etc.
purposes they are non-issue.

BTW, there are several places where ->f_path.mnt access is the right thing
to do - in autofs.  Also a non-issue here...