1. 14 Sep, 2012 1 commit
  2. 15 May, 2012 1 commit
  3. 07 May, 2012 2 commits
  4. 28 Apr, 2012 1 commit
  5. 21 Mar, 2012 1 commit
  6. 29 Feb, 2012 1 commit
  7. 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
  8. 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
  9. 07 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
  10. 15 Mar, 2011 1 commit
  11. 16 Jan, 2011 1 commit
  12. 13 Aug, 2010 1 commit
  13. 23 Dec, 2009 1 commit
  14. 21 Apr, 2009 2 commits
  15. 14 Jan, 2009 4 commits
  16. 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
  17. 27 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
  18. 15 Feb, 2008 2 commits
  19. 08 May, 2007 1 commit
  20. 08 Dec, 2006 1 commit
  21. 07 Dec, 2006 1 commit
  22. 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
  23. 27 Sep, 2006 1 commit
  24. 30 Jun, 2006 1 commit
  25. 28 Apr, 2006 1 commit
  26. 12 Feb, 2006 1 commit
    • Ulrich Drepper's avatar
      [PATCH] fstatat64 support · cff2b760
      Ulrich Drepper authored
      The *at patches introduced fstatat and, due to inusfficient research, I
      used the newfstat functions generally as the guideline.  The result is that
      on 32-bit platforms we don't have all the information needed to implement
      fstatat64.
      
      This patch modifies the code to pass up 64-bit information if
      __ARCH_WANT_STAT64 is defined.  I renamed the syscall entry point to make
      this clear.  Other archs will continue to use the existing code.  On x86-64
      the compat code is implemented using a new sys32_ function.  this is what
      is done for the other stat syscalls as well.
      
      This patch might break some other archs (those which define
      __ARCH_WANT_STAT64 and which already wired up the syscall).  Yet others
      might need changes to accomodate the compatibility mode.  I really don't
      want to do that work because all this stat handling is a mess (more so in
      glibc, but the kernel is also affected).  It should be done by the arch
      maintainers.  I'll provide some stand-alone test shortly.  Those who are
      eager could compile glibc and run 'make check' (no installation needed).
      
      The patch below has been tested on x86 and x86-64.
      Signed-off-by: default avatarUlrich Drepper <drepper@redhat.com>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Andi Kleen <ak@muc.de>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      cff2b760
  27. 19 Jan, 2006 1 commit
    • Ulrich Drepper's avatar
      [PATCH] vfs: *at functions: core · 5590ff0d
      Ulrich Drepper authored
      Here is a series of patches which introduce in total 13 new system calls
      which take a file descriptor/filename pair instead of a single file
      name.  These functions, openat etc, have been discussed on numerous
      occasions.  They are needed to implement race-free filesystem traversal,
      they are necessary to implement a virtual per-thread current working
      directory (think multi-threaded backup software), etc.
      
      We have in glibc today implementations of the interfaces which use the
      /proc/self/fd magic.  But this code is rather expensive.  Here are some
      results (similar to what Jim Meyering posted before).
      
      The test creates a deep directory hierarchy on a tmpfs filesystem.  Then
      rm -fr is used to remove all directories.  Without syscall support I get
      this:
      
      real    0m31.921s
      user    0m0.688s
      sys     0m31.234s
      
      With syscall support the results are much better:
      
      real    0m20.699s
      user    0m0.536s
      sys     0m20.149s
      
      The interfaces are for obvious reasons currently not much used.  But they'll
      be used.  coreutils (and Jeff's posixutils) are already using them.
      Furthermore, code like ftw/fts in libc (maybe even glob) will also start using
      them.  I expect a patch to make follow soon.  Every program which is walking
      the filesystem tree will benefit.
      Signed-off-by: default avatarUlrich Drepper <drepper@redhat.com>
      Signed-off-by: default avatarAlexey Dobriyan <adobriyan@gmail.com>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Al Viro <viro@ftp.linux.org.uk>
      Acked-by: default avatarIngo Molnar <mingo@elte.hu>
      Cc: Michael Kerrisk <mtk-manpages@gmx.net>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      5590ff0d
  28. 16 Apr, 2005 1 commit
    • Linus Torvalds's avatar
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds authored
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4