1. 16 Jan, 2016 1 commit
  2. 09 Nov, 2015 1 commit
  3. 15 Apr, 2015 1 commit
  4. 11 Apr, 2015 1 commit
  5. 08 Nov, 2013 1 commit
  6. 17 Aug, 2013 1 commit
  7. 26 Feb, 2013 1 commit
  8. 20 Dec, 2012 2 commits
  9. 26 Sep, 2012 1 commit
  10. 14 Sep, 2012 2 commits
  11. 15 May, 2012 1 commit
  12. 06 May, 2012 2 commits
  13. 28 Apr, 2012 1 commit
  14. 20 Mar, 2012 1 commit
  15. 28 Feb, 2012 1 commit
  16. 02 Nov, 2011 1 commit
    • Andy Whitcroft's avatar
      readlinkat: ensure we return ENOENT for the empty pathname for normal lookups · 1fa1e7f6
      Andy Whitcroft authored
      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 65cfc672
        Author: Al Viro <viro@zeniv.linux.org.uk>
        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: default avatarAndy Whitcroft <apw@canonical.com>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: <stable@kernel.org>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      1fa1e7f6
  17. 27 Sep, 2011 1 commit
    • Linus Torvalds's avatar
      vfs: remove LOOKUP_NO_AUTOMOUNT flag · b6c8069d
      Linus Torvalds authored
      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: default avatarIan Kent <raven@themaw.net>
      Acked-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      b6c8069d
  18. 06 Aug, 2011 1 commit
    • Linus Torvalds's avatar
      vfs: optimize inode cache access patterns · 3ddcd056
      Linus Torvalds authored
      The inode structure layout is largely random, and some of the vfs paths
      really do care.  The path lookup in particular is already quite D$
      intensive, and profiles show that accessing the 'inode->i_op->xyz'
      fields is quite costly.
      
      We already optimized the dcache to not unnecessarily load the d_op
      structure for members that are often NULL using the DCACHE_OP_xyz bits
      in dentry->d_flags, and this does something very similar for the inode
      ops that are used during pathname lookup.
      
      It also re-orders the fields so that the fields accessed by 'stat' are
      together at the beginning of the inode structure, and roughly in the
      order accessed.
      
      The effect of this seems to be in the 1-2% range for an empty kernel
      "make -j" run (which is fairly kernel-intensive, mostly in filename
      lookup), so it's visible.  The numbers are fairly noisy, though, and
      likely depend a lot on exact microarchitecture.  So there's more tuning
      to be done.
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      3ddcd056
  19. 15 Mar, 2011 1 commit
  20. 15 Jan, 2011 1 commit
  21. 13 Aug, 2010 1 commit
  22. 23 Dec, 2009 1 commit
  23. 20 Apr, 2009 2 commits
  24. 14 Jan, 2009 4 commits
  25. 05 Jan, 2009 1 commit
    • Al Viro's avatar
      inode->i_op is never NULL · acfa4380
      Al Viro authored
      We used to have rather schizophrenic set of checks for NULL ->i_op even
      though it had been eliminated years ago.  You'd need to go out of your
      way to set it to NULL explicitly _and_ a bunch of code would die on
      such inodes anyway.  After killing two remaining places that still
      did that bogosity, all that crap can go away.
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      acfa4380
  26. 26 Jul, 2008 1 commit
    • Al Viro's avatar
      [PATCH] sanitize __user_walk_fd() et.al. · 2d8f3038
      Al Viro authored
      * do not pass nameidata; struct path is all the callers want.
      * switch to new helpers:
      	user_path_at(dfd, pathname, flags, &path)
      	user_path(pathname, &path)
      	user_lpath(pathname, &path)
      	user_path_dir(pathname, &path)  (fail if not a directory)
        The last 3 are trivial macro wrappers for the first one.
      * remove nameidata in callers.
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      2d8f3038
  27. 14 Feb, 2008 2 commits
  28. 08 May, 2007 1 commit
  29. 08 Dec, 2006 1 commit
  30. 07 Dec, 2006 1 commit
  31. 03 Oct, 2006 1 commit
    • David Howells's avatar
      [PATCH] VFS: Make filldir_t and struct kstat deal in 64-bit inode numbers · afefdbb2
      David Howells authored
      These patches make the kernel pass 64-bit inode numbers internally when
      communicating to userspace, even on a 32-bit system.  They are required
      because some filesystems have intrinsic 64-bit inode numbers: NFS3+ and XFS
      for example.  The 64-bit inode numbers are then propagated to userspace
      automatically where the arch supports it.
      
      Problems have been seen with userspace (eg: ld.so) using the 64-bit inode
      number returned by stat64() or getdents64() to differentiate files, and
      failing because the 64-bit inode number space was compressed to 32-bits, and
      so overlaps occur.
      
      This patch:
      
      Make filldir_t take a 64-bit inode number and struct kstat carry a 64-bit
      inode number so that 64-bit inode numbers can be passed back to userspace.
      
      The stat functions then returns the full 64-bit inode number where
      available and where possible.  If it is not possible to represent the inode
      number supplied by the filesystem in the field provided by userspace, then
      error EOVERFLOW will be issued.
      
      Similarly, the getdents/readdir functions now pass the full 64-bit inode
      number to userspace where possible, returning EOVERFLOW instead when a
      directory entry is encountered that can't be properly represented.
      
      Note that this means that some inodes will not be stat'able on a 32-bit
      system with old libraries where they were before - but it does mean that
      there will be no ambiguity over what a 32-bit inode number refers to.
      
      Note similarly that directory scans may be cut short with an error on a
      32-bit system with old libraries where the scan would work before for the
      same reasons.
      
      It is judged unlikely that this situation will occur because modern glibc
      uses 64-bit capable versions of stat and getdents class functions
      exclusively, and that older systems are unlikely to encounter
      unrepresentable inode numbers anyway.
      
      [akpm: alpha build fix]
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Cc: Trond Myklebust <trond.myklebust@fys.uio.no>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      afefdbb2
  32. 27 Sep, 2006 1 commit