summaryrefslogtreecommitdiffstats
path: root/fs/stat.c
diff options
context:
space:
mode:
authorLinus Torvalds <torvalds@linux-foundation.org>2011-09-27 08:12:33 -0700
committerLinus Torvalds <torvalds@linux-foundation.org>2011-09-27 08:12:33 -0700
commitb6c8069d3577481390b3f24a8434ad72a3235594 (patch)
tree43133cbf05bacec887cf010db32589e726a87154 /fs/stat.c
parent815d405ceff0d6964683f033e18b9b23a88fba87 (diff)
downloadop-kernel-dev-b6c8069d3577481390b3f24a8434ad72a3235594.zip
op-kernel-dev-b6c8069d3577481390b3f24a8434ad72a3235594.tar.gz
vfs: remove LOOKUP_NO_AUTOMOUNT flag
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 <raven@themaw.net> Acked-by: Trond Myklebust <Trond.Myklebust@netapp.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'fs/stat.c')
-rw-r--r--fs/stat.c2
1 files changed, 0 insertions, 2 deletions
diff --git a/fs/stat.c b/fs/stat.c
index ba5316f..78a3aa8 100644
--- a/fs/stat.c
+++ b/fs/stat.c
@@ -81,8 +81,6 @@ int vfs_fstatat(int dfd, const char __user *filename, struct kstat *stat,
if (!(flag & AT_SYMLINK_NOFOLLOW))
lookup_flags |= LOOKUP_FOLLOW;
- if (flag & AT_NO_AUTOMOUNT)
- lookup_flags |= LOOKUP_NO_AUTOMOUNT;
if (flag & AT_EMPTY_PATH)
lookup_flags |= LOOKUP_EMPTY;
OpenPOWER on IntegriCloud