Re: [PATCH 00/21] vfs: atomic open v6 (part 2)

[Al Viro]

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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/