1. 31 10月, 2014 1 次提交
  2. 14 10月, 2014 1 次提交
  3. 20 8月, 2014 1 次提交
    • J
      isofs: Fix unbounded recursion when processing relocated directories · 410dd3cf
      Jan Kara 提交于
      We did not check relocated directory in any way when processing Rock
      Ridge 'CL' tag. Thus a corrupted isofs image can possibly have a CL
      entry pointing to another CL entry leading to possibly unbounded
      recursion in kernel code and thus stack overflow or deadlocks (if there
      is a loop created from CL entries).
      
      Fix the problem by not allowing CL entry to point to a directory entry
      with CL entry (such use makes no good sense anyway) and by checking
      whether CL entry doesn't point to itself.
      
      CC: stable@vger.kernel.org
      Reported-by: NChris Evans <cevans@google.com>
      Signed-off-by: NJan Kara <jack@suse.cz>
      410dd3cf
  4. 13 3月, 2014 2 次提交
    • 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
    • F
      fs/isofs/inode.c add __init to init_inodecache() · b3b749b7
      Fabian Frederick 提交于
      init_inodecache is only called by __init init_iso9660_fs
      Signed-off-by: NFabian Frederick <fabf@skynet.be>
      Signed-off-by: NJan Kara <jack@suse.cz>
      b3b749b7
  5. 25 10月, 2013 1 次提交
  6. 01 8月, 2013 1 次提交
    • J
      isofs: Refuse RW mount of the filesystem instead of making it RO · 17b7f7cf
      Jan Kara 提交于
      Refuse RW mount of isofs filesystem. So far we just silently changed it
      to RO mount but when the media is writeable, block layer won't notice
      this change and thus will think device is used RW and will block eject
      button of the drive. That is unexpected by users because for
      non-writeable media eject button works just fine.
      
      Userspace mount(8) command handles this just fine and retries mounting
      with MS_RDONLY set so userspace shouldn't see any regression.  Plus any
      tool mounting isofs is likely confronted with the case of read-only
      media where block layer already refuses to mount the filesystem without
      MS_RDONLY set so our behavior shouldn't be anything new for it.
      Reported-by: NHui Wang <hui.wang@canonical.com>
      Signed-off-by: NJan Kara <jack@suse.cz>
      17b7f7cf
  7. 29 6月, 2013 1 次提交
  8. 13 3月, 2013 1 次提交
    • E
      fs: Readd the fs module aliases. · fa7614dd
      Eric W. Biederman 提交于
      I had assumed that the only use of module aliases for filesystems
      prior to "fs: Limit sys_mount to only request filesystem modules."
      was in request_module.  It turns out I was wrong.  At least mkinitcpio
      in Arch linux uses these aliases.
      
      So readd the preexising aliases, to keep from breaking userspace.
      
      Userspace eventually will have to follow and use the same aliases the
      kernel does.  So at some point we may be delete these aliases without
      problems.  However that day is not today.
      Signed-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>
      fa7614dd
  9. 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
  10. 03 10月, 2012 1 次提交
  11. 21 9月, 2012 1 次提交
  12. 21 3月, 2012 1 次提交
  13. 09 1月, 2012 1 次提交
  14. 04 1月, 2012 2 次提交
  15. 03 11月, 2011 1 次提交
  16. 02 11月, 2011 1 次提交
  17. 23 7月, 2011 1 次提交
    • J
      isofs: Remove global fs lock · d769b3c2
      Jan Kara 提交于
      sbi->s_mutex isn't needed for isofs at all so we can just remove it. Generally,
      since isofs is always mounted read-only, filesystem structure cannot change
      under us.  So buffer_head contents stays constant after it's filled in. That
      leaves us with possible changes of global data structures. Superblock changes
      only during filesystem mount (even remount does not change it), inodes are only
      filled in during reading from disk. So there are no changes of these structures
      to bother about.
      
      Arguments why sbi->s_mutex can be removed at each place:
      isofs_readdir: Accesses sb, inode, filp, local variables => s_mutex not needed
      isofs_lookup: Protected by directory's i_mutex. Accesses sb, inode, dentry,
        local variables => s_mutex not needed
      rock_ridge_symlink_readpage: Protected by page lock. Accesses sb, inode,
        local variables => s_mutex not needed.
      Signed-off-by: NJan Kara <jack@suse.cz>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      d769b3c2
  18. 18 6月, 2011 1 次提交
  19. 10 3月, 2011 1 次提交
  20. 13 1月, 2011 1 次提交
  21. 07 1月, 2011 4 次提交
    • N
      fs: dcache reduce branches in lookup path · fb045adb
      Nick Piggin 提交于
      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: NNick Piggin <npiggin@kernel.dk>
      fb045adb
    • 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
    • N
      fs: change d_hash for rcu-walk · b1e6a015
      Nick Piggin 提交于
      Change d_hash so it may be called from lock-free RCU lookups. See similar
      patch for d_compare for details.
      
      For in-tree filesystems, this is just a mechanical change.
      Signed-off-by: NNick Piggin <npiggin@kernel.dk>
      b1e6a015
    • N
      fs: change d_compare for rcu-walk · 621e155a
      Nick Piggin 提交于
      Change d_compare so it may be called from lock-free RCU lookups. This
      does put significant restrictions on what may be done from the callback,
      however there don't seem to have been any problems with in-tree fses.
      If some strange use case pops up that _really_ cannot cope with the
      rcu-walk rules, we can just add new rcu-unaware callbacks, which would
      cause name lookup to drop out of rcu-walk mode.
      
      For in-tree filesystems, this is just a mechanical change.
      Signed-off-by: NNick Piggin <npiggin@kernel.dk>
      621e155a
  22. 29 10月, 2010 1 次提交
  23. 28 10月, 2010 1 次提交
  24. 26 10月, 2010 1 次提交
    • J
      isofs: Fix isofs_get_blocks for 8TB files · fde214d4
      Jan Kara 提交于
      Currently isofs_get_blocks() was limited to handle only 4TB files on 32-bit
      architectures because of unnecessary use of iblock variable which was signed
      long. Just remove the variable. The error messages that were using this
      variable should have rather used b_off anyway because that is the block we
      are currently mapping.
      Signed-off-by: NJan Kara <jack@suse.cz>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      fde214d4
  25. 05 10月, 2010 2 次提交
    • A
      BKL: Remove BKL from isofs · 4f819a78
      Arnd Bergmann 提交于
      As in other file systems, we can replace the big kernel lock
      with a private mutex in isofs. This means we can now access
      multiple file systems concurrently, but it also means that
      we serialize readdir and lookup across sleeping operations
      which previously released the big kernel lock. This should
      not matter though, as these operations are in practice
      serialized through the hardware access.
      
      The isofs_get_blocks functions now does not take any lock
      any more, it used to recursively get the BKL. After looking
      at the code for hours, I convinced myself that it was never
      needed here anyway, because it only reads constant fields
      of the inode and writes to a buffer head array that is
      at this time only visible to the caller.
      
      The get_sb and fill_super operations do not need the locking
      at all because they operate on a file system that is either
      about to be created or to be destroyed but in either case
      is not visible to other threads.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      4f819a78
    • 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
  26. 11 8月, 2010 1 次提交
    • J
      isofs: Fix lseek() to position beyond 4 GB · 66a362a2
      Jan Andres 提交于
      isofs supports files larger than 4 GB by using multi-extent files.
      However an lseek() to a position beyond 4 GB in such a file will
      fail with EINVAL, because s_maxbytes in the isofs superblock is
      initialized to 2^32-1, and generic_file_llseek() checks against
      that value.
      
      I therefore suggest increasing the value of s_maxbytes to have
      full support for large files in isofs. With multi-extent files, file
      size is only limited by the maximum size of the file system (8 TB),
      so this seems a reasonable value for s_maxbytes.
      Signed-off-by: NJan Andres <jandres@gmx.net>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      66a362a2
  27. 24 9月, 2009 1 次提交
    • T
      fs: Make unload_nls() NULL pointer safe · 6d729e44
      Thomas Gleixner 提交于
      Most call sites of unload_nls() do:
      	if (nls)
      		unload_nls(nls);
      
      Check the pointer inside unload_nls() like we do in kfree() and
      simplify the call sites.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Steve French <sfrench@us.ibm.com>
      Cc: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
      Cc: Roman Zippel <zippel@linux-m68k.org>
      Cc: Dave Kleikamp <shaggy@linux.vnet.ibm.com>
      Cc: Petr Vandrovec <vandrove@vc.cvut.cz>
      Cc: Anton Altaparmakov <aia21@cantab.net>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      6d729e44
  28. 11 7月, 2009 1 次提交
  29. 19 6月, 2009 3 次提交
  30. 12 6月, 2009 1 次提交
    • 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
  31. 03 4月, 2009 1 次提交
  32. 28 3月, 2009 1 次提交