1. 07 6月, 2014 1 次提交
    • F
      ufs: sb mutex merge + mutex_destroy · 0244756e
      Fabian Frederick 提交于
      Commit 788257d6 ("ufs: remove the BKL") replaced BKL with mutex
      protection using functions lock_ufs, unlock_ufs and struct mutex 'mutex'
      in sb_info.
      
      Commit b6963327 ("ufs: drop lock/unlock super") removed lock/unlock
      super and added struct mutex 's_lock' in sb_info.
      
      Those 2 mutexes are generally locked/unlocked at the same time except in
      allocation (balloc, ialloc).
      
      This patch merges the 2 mutexes and propagates first commit solution.
      It also adds mutex destruction before kfree during ufs_fill_super
      failure and ufs_put_super.
      
      [akpm@linux-foundation.org: avoid ifdefs, return -EROFS not -EINVAL]
      Signed-off-by: NFabian Frederick <fabf@skynet.be>
      Cc: Evgeniy Dushistov <dushistov@mail.ru>
      Cc: "Chen, Jet" <jet.chen@intel.com>
      Cc: Wu Fengguang <fengguang.wu@intel.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      0244756e
  2. 08 4月, 2014 4 次提交
  3. 13 3月, 2014 1 次提交
    • T
      fs: push sync_filesystem() down to the file system's remount_fs() · 02b9984d
      Theodore Ts'o 提交于
      Previously, the no-op "mount -o mount /dev/xxx" operation when the
      file system is already mounted read-write causes an implied,
      unconditional syncfs().  This seems pretty stupid, and it's certainly
      documented or guaraunteed to do this, nor is it particularly useful,
      except in the case where the file system was mounted rw and is getting
      remounted read-only.
      
      However, it's possible that there might be some file systems that are
      actually depending on this behavior.  In most file systems, it's
      probably fine to only call sync_filesystem() when transitioning from
      read-write to read-only, and there are some file systems where this is
      not needed at all (for example, for a pseudo-filesystem or something
      like romfs).
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      Cc: linux-fsdevel@vger.kernel.org
      Cc: Christoph Hellwig <hch@infradead.org>
      Cc: Artem Bityutskiy <dedekind1@gmail.com>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Evgeniy Dushistov <dushistov@mail.ru>
      Cc: Jan Kara <jack@suse.cz>
      Cc: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
      Cc: Anders Larsen <al@alarsen.net>
      Cc: Phillip Lougher <phillip@squashfs.org.uk>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Mikulas Patocka <mikulas@artax.karlin.mff.cuni.cz>
      Cc: Petr Vandrovec <petr@vandrovec.name>
      Cc: xfs@oss.sgi.com
      Cc: linux-btrfs@vger.kernel.org
      Cc: linux-cifs@vger.kernel.org
      Cc: samba-technical@lists.samba.org
      Cc: codalist@coda.cs.cmu.edu
      Cc: linux-ext4@vger.kernel.org
      Cc: linux-f2fs-devel@lists.sourceforge.net
      Cc: fuse-devel@lists.sourceforge.net
      Cc: cluster-devel@redhat.com
      Cc: linux-mtd@lists.infradead.org
      Cc: jfs-discussion@lists.sourceforge.net
      Cc: linux-nfs@vger.kernel.org
      Cc: linux-nilfs@vger.kernel.org
      Cc: linux-ntfs-dev@lists.sourceforge.net
      Cc: ocfs2-devel@oss.oracle.com
      Cc: reiserfs-devel@vger.kernel.org
      02b9984d
  4. 04 3月, 2013 1 次提交
    • E
      fs: Limit sys_mount to only request filesystem modules. · 7f78e035
      Eric W. Biederman 提交于
      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: NSerge Hallyn <serge.hallyn@canonical.com>
      Acked-by: NKees Cook <keescook@chromium.org>
      Reported-by: NKees Cook <keescook@google.com>
      Signed-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>
      7f78e035
  5. 10 10月, 2012 1 次提交
  6. 03 10月, 2012 1 次提交
  7. 23 7月, 2012 3 次提交
    • A
      fs/ufs: get rid of write_super · 9e9ad5f4
      Artem Bityutskiy 提交于
      This patch makes UFS stop using the VFS '->write_super()' method along with
      the 's_dirt' superblock flag, because they are on their way out.
      
      The way we implement this is that we schedule a delay job instead relying on
      's_dirt' and '->write_super()'.
      
      The whole "superblock write-out" VFS infrastructure is served by the
      'sync_supers()' kernel thread, which wakes up every 5 (by default) seconds and
      writes out all dirty superblocks using the '->write_super()' call-back.  But the
      problem with this thread is that it wastes power by waking up the system every
      5 seconds, even if there are no diry superblocks, or there are no client
      file-systems which would need this (e.g., btrfs does not use
      '->write_super()'). So we want to kill it completely and thus, we need to make
      file-systems to stop using the '->write_super()' VFS service, and then remove
      it together with the kernel thread.
      
      Tested using fsstress from the LTP project.
      Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      9e9ad5f4
    • A
      fs/ufs: re-arrange the code a bit · 7bd54ef7
      Artem Bityutskiy 提交于
      This patch does not do any functional changes. It only moves 3 functions
      in fs/ufs/super.c a little bit up in order to prepare for further changes
      where I'll need this new arrangement to avoid forward declarations.
      Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      7bd54ef7
    • A
      fs/ufs: remove extra superblock write on unmount · 65e5e83f
      Artem Bityutskiy 提交于
      UFS calls 'ufs_write_super()' from 'ufs_put_super()' in order to write the
      superblocks to the media. However, it is not needed because VFS calls
      '->sync_fs()' before calling '->put_super()' - so by the time we are in
      'ufs_write_super()', the superblocks are already synchronized.
      Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      65e5e83f
  8. 11 5月, 2012 1 次提交
    • L
      vfs: make it possible to access the dentry hash/len as one 64-bit entry · 26fe5750
      Linus Torvalds 提交于
      This allows comparing hash and len in one operation on 64-bit
      architectures.  Right now only __d_lookup_rcu() takes advantage of this,
      since that is the case we care most about.
      
      The use of anonymous struct/unions hides the alternate 64-bit approach
      from most users, the exception being a few cases where we initialize a
      'struct qstr' with a static initializer.  This makes the problematic
      cases use a new QSTR_INIT() helper function for that (but initializing
      just the name pointer with a "{ .name = xyzzy }" initializer remains
      valid, as does just copying another qstr structure).
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      26fe5750
  9. 29 3月, 2012 1 次提交
  10. 21 3月, 2012 2 次提交
  11. 07 1月, 2012 1 次提交
  12. 04 1月, 2012 1 次提交
    • A
      vfs: fix the stupidity with i_dentry in inode destructors · 6b520e05
      Al Viro 提交于
      Seeing that just about every destructor got that INIT_LIST_HEAD() copied into
      it, there is no point whatsoever keeping this INIT_LIST_HEAD in inode_init_once();
      the cost of taking it into inode_init_always() will be negligible for pipes
      and sockets and negative for everything else.  Not to mention the removal of
      boilerplate code from ->destroy_inode() instances...
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      6b520e05
  13. 31 3月, 2011 1 次提交
  14. 03 3月, 2011 1 次提交
    • A
      ufs: remove the BKL · 788257d6
      Arnd Bergmann 提交于
      This introduces a new per-superblock mutex in UFS to replace
      the big kernel lock. I have been careful to avoid nested
      calls to lock_ufs and to get the lock order right with
      respect to other mutexes, in particular lock_super.
      
      I did not make any attempt to prove that the big kernel
      lock is not needed in a particular place in the code,
      which is very possible.
      
      The mutex has a significant performance impact, so it is only
      used on SMP or PREEMPT configurations.
      
      As Nick Piggin noticed, any allocation inside of the lock
      may end up deadlocking when we get to ufs_getfrag_block
      in the reclaim task, so we now use GFP_NOFS.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Tested-by: NNick Bowler <nbowler@elliptictech.com>
      Cc: Evgeniy Dushistov <dushistov@mail.ru>
      Cc: Nick Piggin <npiggin@gmail.com>
      788257d6
  15. 07 1月, 2011 1 次提交
    • N
      fs: icache RCU free inodes · fa0d7e3d
      Nick Piggin 提交于
      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: NNick Piggin <npiggin@kernel.dk>
      fa0d7e3d
  16. 29 10月, 2010 1 次提交
  17. 05 10月, 2010 1 次提交
    • J
      BKL: Explicitly add BKL around get_sb/fill_super · db719222
      Jan Blunck 提交于
      This patch is a preparation necessary to remove the BKL from do_new_mount().
      It explicitly adds calls to lock_kernel()/unlock_kernel() around
      get_sb/fill_super operations for filesystems that still uses the BKL.
      
      I've read through all the code formerly covered by the BKL inside
      do_kern_mount() and have satisfied myself that it doesn't need the BKL
      any more.
      
      do_kern_mount() is already called without the BKL when mounting the rootfs
      and in nfsctl. do_kern_mount() calls vfs_kern_mount(), which is called
      from various places without BKL: simple_pin_fs(), nfs_do_clone_mount()
      through nfs_follow_mountpoint(), afs_mntpt_do_automount() through
      afs_mntpt_follow_link(). Both later functions are actually the filesystems
      follow_link inode operation. vfs_kern_mount() is calling the specified
      get_sb function and lets the filesystem do its job by calling the given
      fill_super function.
      
      Therefore I think it is safe to push down the BKL from the VFS to the
      low-level filesystems get_sb/fill_super operation.
      
      [arnd: do not add the BKL to those file systems that already
             don't use it elsewhere]
      Signed-off-by: NJan Blunck <jblunck@infradead.org>
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Cc: Matthew Wilcox <matthew@wil.cx>
      Cc: Christoph Hellwig <hch@infradead.org>
      db719222
  18. 10 8月, 2010 1 次提交
  19. 28 5月, 2010 1 次提交
    • T
      ufs: permit mounting of BorderWare filesystems · d27d7a9a
      Thomas Stewart 提交于
      I recently had to recover some files from an old broken machine that was
      running BorderWare Document Gateway.  It's basically a drop in web server
      for sharing files.  From the look of the init process and using strings on
      of a few files it seems to be based on FreeBSD 3.3.
      
      The process turned out to be more difficult than I imagined, but to cut a
      long story short BorderWare in their wisdom use a nonstandard magic number
      in their UFS (ufstype=44bsd) file systems.  Thus Linux refuses to mount
      the file systems in order to recover the data.  After a bit of hunting I
      was able to make a quick fix to fs/ufs/super.c in order to detect the new
      magic number.
      
      I assume that this number is the same for all installations.  It's quite
      easy to find out from ufs_fs.h.  The superblock sits 8k into the block
      device and the magic number its 1372 bytes into the superblock struct.
      
      # dd if=/dev/sda5 skip=$(( 8192 + 1372 )) bs=1 count=4 2> /dev/null | hd
      00000000  97 26 24 0f                                       |.&$.|
      #
      Signed-off-by: NThomas Stewart <thomas@stewarts.org.uk>
      Cc: Evgeniy Dushistov <dushistov@mail.ru>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      d27d7a9a
  20. 24 5月, 2010 6 次提交
  21. 13 3月, 2010 1 次提交
  22. 05 3月, 2010 2 次提交
  23. 16 12月, 2009 1 次提交
  24. 12 6月, 2009 5 次提交
    • C
      ufs: add ->sync_fs · 8c800656
      Christoph Hellwig 提交于
      Add a ->sync_fs method for data integrity syncs, and reimplement
      ->write_super ontop of it.
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      8c800656
    • A
      Push BKL down into ->remount_fs() · 337eb00a
      Alessio Igor Bogani 提交于
      [xfs, btrfs, capifs, shmem don't need BKL, exempt]
      Signed-off-by: NAlessio Igor Bogani <abogani@texware.it>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      337eb00a
    • C
      ->write_super lock_super pushdown · ebc1ac16
      Christoph Hellwig 提交于
      Push down lock_super into ->write_super instances and remove it from the
      caller.
      
      Following filesystem don't need ->s_lock in ->write_super and are skipped:
      
       * bfs, nilfs2 - no other uses of s_lock and have internal locks in
      	->write_super
       * ext2 - uses BKL in ext2_write_super and has internal calls without s_lock
       * reiserfs - no other uses of s_lock as has reiserfs_write_lock (BKL) in
       	->write_super
       * xfs - no other uses of s_lock and uses internal lock (buffer lock on
      	superblock buffer) to serialize ->write_super.  Also xfs_fs_write_super
      	is superflous and will go away in the next merge window
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      ebc1ac16
    • A
      Push lock_super() into the ->remount_fs() of filesystems that care about it · bbd6851a
      Al Viro 提交于
      Note that since we can't run into contention between remount_fs and write_super
      (due to exclusion on s_umount), we have to care only about filesystems that
      touch lock_super() on their own.  Out of those ext3, ext4, hpfs, sysv and ufs
      do need it; fat doesn't since its ->remount_fs() only accesses assign-once
      data (basically, it's "we have no atime on directories and only have atime on
      files for vfat; force nodiratime and possibly noatime into *flags").
      
      [folded a build fix from hch]
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      bbd6851a
    • C
      push BKL down into ->put_super · 6cfd0148
      Christoph Hellwig 提交于
      Move BKL into ->put_super from the only caller.  A couple of
      filesystems had trivial enough ->put_super (only kfree and NULLing of
      s_fs_info + stuff in there) to not get any locking: coda, cramfs, efs,
      hugetlbfs, omfs, qnx4, shmem, all others got the full treatment.  Most
      of them probably don't need it, but I'd rather sort that out individually.
      Preferably after all the other BKL pushdowns in that area.
      
      [AV: original used to move lock_super() down as well; these changes are
      removed since we don't do lock_super() at all in generic_shutdown_super()
      now]
      [AV: fuse, btrfs and xfs are known to need no damn BKL, exempt]
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      6cfd0148