1. 04 Mar, 2013 1 commit
    • Eric W. Biederman's avatar
      fs: Limit sys_mount to only request filesystem modules. · 7f78e035
      Eric W. Biederman authored
      Modify the request_module to prefix the file system type with "fs-"
      and add aliases to all of the filesystems that can be built as modules
      to match.
      
      A common practice is to build all of the kernel code and leave code
      that is not commonly needed as modules, with the result that many
      users are exposed to any bug anywhere in the kernel.
      
      Looking for filesystems with a fs- prefix limits the pool of possible
      modules that can be loaded by mount to just filesystems trivially
      making things safer with no real cost.
      
      Using aliases means user space can control the policy of which
      filesystem modules are auto-loaded by editing /etc/modprobe.d/*.conf
      with blacklist and alias directives.  Allowing simple, safe,
      well understood work-arounds to known problematic software.
      
      This also addresses a rare but unfortunate problem where the filesystem
      name is not the same as it's module name and module auto-loading
      would not work.  While writing this patch I saw a handful of such
      cases.  The most significant being autofs that lives in the module
      autofs4.
      
      This is relevant to user namespaces because we can reach the request
      module in get_fs_type() without having any special permissions, and
      people get uncomfortable when a user specified string (in this case
      the filesystem type) goes all of the way to request_module.
      
      After having looked at this issue I don't think there is any
      particular reason to perform any filtering or permission checks beyond
      making it clear in the module request that we want a filesystem
      module.  The common pattern in the kernel is to call request_module()
      without regards to the users permissions.  In general all a filesystem
      module does once loaded is call register_filesystem() and go to sleep.
      Which means there is not much attack surface exposed by loading a
      filesytem module unless the filesystem is mounted.  In a user
      namespace filesystems are not mounted unless .fs_flags = FS_USERNS_MOUNT,
      which most filesystems do not set today.
      Acked-by: default avatarSerge Hallyn <serge.hallyn@canonical.com>
      Acked-by: default avatarKees Cook <keescook@chromium.org>
      Reported-by: default avatarKees Cook <keescook@google.com>
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      7f78e035
  2. 23 Feb, 2013 1 commit
  3. 20 Dec, 2012 1 commit
  4. 03 Oct, 2012 1 commit
  5. 21 Sep, 2012 1 commit
  6. 31 Jul, 2012 1 commit
  7. 14 Jul, 2012 2 commits
  8. 06 May, 2012 1 commit
  9. 21 Mar, 2012 2 commits
  10. 20 Mar, 2012 1 commit
  11. 04 Jan, 2012 6 commits
  12. 19 Nov, 2011 2 commits
  13. 02 Nov, 2011 1 commit
  14. 21 Jul, 2011 1 commit
  15. 28 May, 2011 1 commit
  16. 26 May, 2011 2 commits
  17. 24 Mar, 2011 1 commit
    • Akinobu Mita's avatar
      bitops: remove minix bitops from asm/bitops.h · 61f2e7b0
      Akinobu Mita authored
      minix bit operations are only used by minix filesystem and useless by
      other modules.  Because byte order of inode and block bitmaps is different
      on each architecture like below:
      
      m68k:
      	big-endian 16bit indexed bitmaps
      
      h8300, microblaze, s390, sparc, m68knommu:
      	big-endian 32 or 64bit indexed bitmaps
      
      m32r, mips, sh, xtensa:
      	big-endian 32 or 64bit indexed bitmaps for big-endian mode
      	little-endian bitmaps for little-endian mode
      
      Others:
      	little-endian bitmaps
      
      In order to move minix bit operations from asm/bitops.h to architecture
      independent code in minix filesystem, this provides two config options.
      
      CONFIG_MINIX_FS_BIG_ENDIAN_16BIT_INDEXED is only selected by m68k.
      CONFIG_MINIX_FS_NATIVE_ENDIAN is selected by the architectures which use
      native byte order bitmaps (h8300, microblaze, s390, sparc, m68knommu,
      m32r, mips, sh, xtensa).  The architectures which always use little-endian
      bitmaps do not select these options.
      
      Finally, we can remove minix bit operations from asm/bitops.h for all
      architectures.
      Signed-off-by: default avatarAkinobu Mita <akinobu.mita@gmail.com>
      Acked-by: default avatarArnd Bergmann <arnd@arndb.de>
      Acked-by: default avatarGreg Ungerer <gerg@uclinux.org>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Cc: Roman Zippel <zippel@linux-m68k.org>
      Cc: Andreas Schwab <schwab@linux-m68k.org>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
      Cc: Michal Simek <monstr@monstr.eu>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Hirokazu Takata <takata@linux-m32r.org>
      Acked-by: default avatarRalf Baechle <ralf@linux-mips.org>
      Acked-by: default avatarPaul Mundt <lethal@linux-sh.org>
      Cc: Chris Zankel <chris@zankel.net>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      61f2e7b0
  18. 10 Mar, 2011 1 commit
  19. 03 Mar, 2011 1 commit
  20. 13 Jan, 2011 1 commit
  21. 07 Jan, 2011 2 commits
    • Nick Piggin's avatar
      fs: dcache reduce branches in lookup path · fb045adb
      Nick Piggin authored
      Reduce some branches and memory accesses in dcache lookup by adding dentry
      flags to indicate common d_ops are set, rather than having to check them.
      This saves a pointer memory access (dentry->d_op) in common path lookup
      situations, and saves another pointer load and branch in cases where we
      have d_op but not the particular operation.
      
      Patched with:
      
      git grep -E '[.>]([[:space:]])*d_op([[:space:]])*=' | xargs sed -e 's/\([^\t ]*\)->d_op = \(.*\);/d_set_d_op(\1, \2);/' -e 's/\([^\t ]*\)\.d_op = \(.*\);/d_set_d_op(\&\1, \2);/' -i
      Signed-off-by: default avatarNick Piggin <npiggin@kernel.dk>
      fb045adb
    • Nick Piggin's avatar
      fs: icache RCU free inodes · fa0d7e3d
      Nick Piggin authored
      RCU free the struct inode. This will allow:
      
      - Subsequent store-free path walking patch. The inode must be consulted for
        permissions when walking, so an RCU inode reference is a must.
      - sb_inode_list_lock to be moved inside i_lock because sb list walkers who want
        to take i_lock no longer need to take sb_inode_list_lock to walk the list in
        the first place. This will simplify and optimize locking.
      - Could remove some nested trylock loops in dcache code
      - Could potentially simplify things a bit in VM land. Do not need to take the
        page lock to follow page->mapping.
      
      The downsides of this is the performance cost of using RCU. In a simple
      creat/unlink microbenchmark, performance drops by about 10% due to inability to
      reuse cache-hot slab objects. As iterations increase and RCU freeing starts
      kicking over, this increases to about 20%.
      
      In cases where inode lifetimes are longer (ie. many inodes may be allocated
      during the average life span of a single inode), a lot of this cache reuse is
      not applicable, so the regression caused by this patch is smaller.
      
      The cache-hot regression could largely be avoided by using SLAB_DESTROY_BY_RCU,
      however this adds some complexity to list walking and store-free path walking,
      so I prefer to implement this at a later date, if it is shown to be a win in
      real situations. I haven't found a regression in any non-micro benchmark so I
      doubt it will be a problem.
      Signed-off-by: default avatarNick Piggin <npiggin@kernel.dk>
      fa0d7e3d
  22. 29 Oct, 2010 1 commit
  23. 26 Oct, 2010 1 commit
  24. 10 Sep, 2010 1 commit
  25. 09 Aug, 2010 6 commits
    • Al Viro's avatar
      switch minix to ->evict_inode(), fix write_inode/delete_inode race · 5ccb4a78
      Al Viro authored
      We need to wait for completion of possible writeback in progress
      before we clear on-disk inode during deletion.
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      5ccb4a78
    • Christoph Hellwig's avatar
      remove inode_setattr · 1025774c
      Christoph Hellwig authored
      Replace inode_setattr with opencoded variants of it in all callers.  This
      moves the remaining call to vmtruncate into the filesystem methods where it
      can be replaced with the proper truncate sequence.
      
      In a few cases it was obvious that we would never end up calling vmtruncate
      so it was left out in the opencoded variant:
      
       spufs: explicitly checks for ATTR_SIZE earlier
       btrfs,hugetlbfs,logfs,dlmfs: explicitly clears ATTR_SIZE earlier
       ufs: contains an opencoded simple_seattr + truncate that sets the filesize just above
      
      In addition to that ncpfs called inode_setattr with handcrafted iattrs,
      which allowed to trim down the opencoded variant.
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      1025774c
    • Christoph Hellwig's avatar
      add missing setattr methods · d39aae9e
      Christoph Hellwig authored
      For the new truncate sequence every filesystem that wants to truncate on-disk
      state needs a seattr method.  Convert the remaining filesystems that implement
      the truncate inode operation to have its own setattr method.
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      d39aae9e
    • Christoph Hellwig's avatar
      get rid of block_write_begin_newtrunc · 155130a4
      Christoph Hellwig authored
      Move the call to vmtruncate to get rid of accessive blocks to the callers
      in preparation of the new truncate sequence and rename the non-truncating
      version to block_write_begin.
      
      While we're at it also remove several unused arguments to block_write_begin.
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      155130a4
    • Christoph Hellwig's avatar
      introduce __block_write_begin · 6e1db88d
      Christoph Hellwig authored
      Split up the block_write_begin implementation - __block_write_begin is a new
      trivial wrapper for block_prepare_write that always takes an already
      allocated page and can be either called from block_write_begin or filesystem
      code that already has a page allocated.  Remove the handling of already
      allocated pages from block_write_begin after switching all callers that
      do it to __block_write_begin.
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      6e1db88d
    • Christoph Hellwig's avatar
      clean up write_begin usage for directories in pagecache · f4e420dc
      Christoph Hellwig authored
      For filesystem that implement directories in pagecache we call
      block_write_begin with an already allocated page for this code, while the
      normal regular file write path uses the default block_write_begin behaviour.
      
      Get rid of the __foofs_write_begin helper and opencode the normal write_begin
      call in foofs_write_begin, while adding a new foofs_prepare_chunk helper for
      the directory code.  The added benefit is that foofs_prepare_chunk has
      a much saner calling convention.
      
      Note that the interruptible flag passed into block_write_begin is always
      ignored if we already pass in a page (see next patch for details), and
      we never were doing truncations of exessive blocks for this case either so we
      can switch directly to block_write_begin_newtrunc.
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      f4e420dc