From mboxrd@z Thu Jan 1 00:00:00 1970 From: Al Viro Subject: Re: [PATCH 00/21] vfs: atomic open v6 (part 2) Date: Thu, 14 Jun 2012 09:08:00 +0100 Message-ID: <20120614080800.GA14898@ZenIV.linux.org.uk> References: <20120613112112.GA10597@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Miklos Szeredi , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, torvalds@linux-foundation.org, dhowells@redhat.com, mszeredi@suse.cz To: Christoph Hellwig Return-path: Content-Disposition: inline In-Reply-To: <20120613112112.GA10597@infradead.org> Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Wed, Jun 13, 2012 at 07:21:12AM -0400, Christoph Hellwig wrote: > It also shows that were are really close to getting nameidata out of the > filesystem. The remaning issues are kern_path_parent usages in devtmpfs > and audit_watch, as well as direct access to nd->path in > proc_pid_follow_link. A hacky patch to demonstrate this is below (not > intended for submission). Those are easily handled - kern_path_parent() ones are begging for something like int path_lookup_locked(char *name, struct path *path) resulting in dentry/vfsmount pair stored in path, dentry possibly negative and its parent known to have locked inode (i.e. path->dentry->d_parent is stable until we unlock path->dentry->d_parent->d_inode->i_mutex). And proc_pid_follow_link() is easier yet - explicit nd_jump_link(nd, path), to be called by magical symlinks' ->follow_link(). Can do.. As for Miklos' objection re overlayfs - I'm tempted to make path_openat() take struct file * as explicit argument, convert the existing callers into path_openat(get_empty_filp(), ...) and let the stacking ones use that. My objection against opendata is that it's both an offense against Occam's Razor (i.e. opaque object where none is needed) *and* not really opaque at that - restrictions on the sequence of operations are non-trivial and that has at least as high potential for bugs as bogus fput() done by broken fs.