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-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
