linux-toradex.git/include/linux/namei.h, branch v3.7

new helper: done_path_create()

2012-07-29T17:24:13+00:00

releases what needs to be released after {kern,user}_path_create()

Signed-off-by: Al Viro

fs: add nd_jump_link

2012-07-14T12:35:40+00:00

Add a helper that abstracts out the jump to an already parsed struct path
from ->follow_link operation from procfs.  Not only does this clean up
the code by moving the two sides of this game into a single helper, but
it also prepares for making struct nameidata private to namei.c

Signed-off-by: Christoph Hellwig 
Signed-off-by: Al Viro

get rid of kern_path_parent()

2012-07-14T12:35:02+00:00

all callers want the same thing, actually - a kinda-sorta analog of
kern_path_create().  I.e. they want parent vfsmount/dentry (with
->i_mutex held, to make sure the child dentry is still their child)
+ the child dentry.

Signed-off-by Al Viro

vfs: remove open intents from nameidata

2012-07-14T12:33:18+00:00

All users of open intents have been converted to use ->atomic_{open,create}.

This patch gets rid of nd->intent.open and related infrastructure.

Signed-off-by: Miklos Szeredi 
Signed-off-by: Al Viro

readlinkat: ensure we return ENOENT for the empty pathname for normal lookups

2011-11-02T11:53:42+00:00

Since the commit below which added O_PATH support to the *at() calls, the
error return for readlink/readlinkat for the empty pathname has switched
from ENOENT to EINVAL:

  commit 65cfc6722361570bfe255698d9cd4dccaf47570d
  Author: Al Viro 
  Date:   Sun Mar 13 15:56:26 2011 -0400

    readlinkat(), fchownat() and fstatat() with empty relative pathnames

This is both unexpected for userspace and makes readlink/readlinkat
inconsistant with all other interfaces; and inconsistant with our stated
return for these pathnames.

As the readlinkat call does not have a flags parameter we cannot use the
AT_EMPTY_PATH approach used in the other calls.  Therefore expose whether
the original path is infact entry via a new user_path_at_empty() path
lookup function.  Use this to determine whether to default to EINVAL or
ENOENT for failures.

Addresses http://bugs.launchpad.net/bugs/817187

[akpm@linux-foundation.org: remove unused getname_flags()]
Signed-off-by: Andy Whitcroft 
Cc: Christoph Hellwig 
Cc: Al Viro 
Cc: 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Christoph Hellwig

vfs: remove LOOKUP_NO_AUTOMOUNT flag

2011-09-27T15:12:33+00:00

That flag no longer makes sense, since we don't look up automount points
as eagerly any more.  Additionally, it turns out that the NO_AUTOMOUNT
handling was buggy to begin with: it would avoid automounting even for
cases where we really *needed* to do the automount handling, and could
return ENOENT for autofs entries that hadn't been instantiated yet.

With our new non-eager automount semantics, one discussion has been
about adding a AT_AUTOMOUNT flag to vfs_fstatat (and thus the
newfstatat() and fstatat64() system calls), but it's probably not worth
it: you can always force at least directory automounting by simply
adding the final '/' to the filename, which works for *all* of the stat
family system calls, old and new.

So AT_NO_AUTOMOUNT (and thus LOOKUP_NO_AUTOMOUNT) really were just a
result of our bad default behavior.

Acked-by: Ian Kent 
Acked-by: Trond Myklebust 
Signed-off-by: Linus Torvalds

vfs pathname lookup: Add LOOKUP_AUTOMOUNT flag

2011-09-27T00:44:55+00:00

Since we've now turned around and made LOOKUP_FOLLOW *not* force an
automount, we want to add the ability to force an automount event on
lookup even if we don't happen to have one of the other flags that force
it implicitly (LOOKUP_OPEN, LOOKUP_DIRECTORY, LOOKUP_PARENT..)

Most cases will never want to use this, since you'd normally want to
delay automounting as long as possible, which usually implies
LOOKUP_OPEN (when we open a file or directory, we really cannot avoid
the automount any more).

But Trond argued sufficiently forcefully that at a minimum bind mounting
a file and quotactl will want to force the automount lookup.  Some other
cases (like nfs_follow_remote_path()) could use it too, although
LOOKUP_DIRECTORY would work there as well.

This commit just adds the flag and logic, no users yet, though.  It also
doesn't actually touch the LOOKUP_NO_AUTOMOUNT flag that is related, and
was made irrelevant by the same change that made us not follow on
LOOKUP_FOLLOW.

Cc: Trond Myklebust 
Cc: Ian Kent 
Cc: Jeff Layton 
Cc: Miklos Szeredi 
Cc: David Howells 
Cc: Al Viro 
Cc: Greg KH 
Signed-off-by: Linus Torvalds

switch vfs_path_lookup() to struct path

2011-07-20T05:44:14+00:00

Signed-off-by: Al Viro

new helpers: kern_path_create/user_path_create

2011-07-20T05:44:05+00:00

combination of kern_path_parent() and lookup_create().  Does *not*
expose struct nameidata to caller.  Syscalls converted to that...

Signed-off-by: Al Viro

kill LOOKUP_CONTINUE

2011-07-20T05:44:03+00:00

LOOKUP_PARENT is equivalent to it now

Signed-off-by: Al Viro