1. 06 9月, 2009 1 次提交
  2. 18 8月, 2009 2 次提交
    • E
      ext4: Add feature set check helper for mount & remount paths · a13fb1a4
      Eric Sandeen 提交于
      A user reported that although his root ext4 filesystem was mounting
      fine, other filesystems would not mount, with the:
      
      "Filesystem with huge files cannot be mounted RDWR without CONFIG_LBDAF"
      
      error on his 32-bit box built without CONFIG_LBDAF.  This is because
      the test at mount time for this situation was not being re-checked
      on remount, and the normal boot process makes an ro->rw transition,
      so this was being missed.
      
      Refactor to make a common helper function to test the filesystem
      features against the type of mount request (RO vs. RW) so that we 
      stay consistent.
      
      Addresses Red-Hat-Bugzilla: #517650
      Signed-off-by: NEric Sandeen <sandeen@redhat.com>
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      a13fb1a4
    • E
      ext4: reject too-large filesystems on 32-bit kernels · bf43d84b
      Eric Sandeen 提交于
      ext4 will happily mount a > 16T filesystem on a 32-bit box, but
      this is not safe; writes to the block device will wrap past 16T
      and the page cache can't index past 16T (232 index * 4k pages).
      
      Adding another test to the existing "too many sectors" test
      should do the trick.
      
      Add a comment, a relevant return value, and fix the reference
      to the CONFIG_LBD(AF) option as well.
      Signed-off-by: NEric Sandeen <sandeen@redhat.com>
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      bf43d84b
  3. 28 7月, 2009 1 次提交
  4. 24 6月, 2009 1 次提交
  5. 19 6月, 2009 1 次提交
  6. 13 6月, 2009 3 次提交
  7. 12 6月, 2009 6 次提交
    • 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
    • A
      No need to do lock_super() for exclusion in generic_shutdown_super() · a9e220f8
      Al Viro 提交于
      We can't run into contention on it.  All other callers of lock_super()
      either hold s_umount (and we have it exclusive) or hold an active
      reference to superblock in question, which prevents the call of
      generic_shutdown_super() while the reference is held.  So we can
      replace lock_super(s) with get_fs_excl() in generic_shutdown_super()
      (and corresponding change for unlock_super(), of course).
      
      Since ext4 expects s_lock held for its put_super, take lock_super()
      into it.  The rest of filesystems do not care at all.
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      a9e220f8
    • C
      remove ->write_super call in generic_shutdown_super · 8c85e125
      Christoph Hellwig 提交于
      We just did a full fs writeout using sync_filesystem before, and if
      that's not enough for the filesystem it can perform it's own writeout
      in ->put_super, which many filesystems already do.
      
      Move a call to foofs_write_super into every foofs_put_super for now to
      guarantee identical behaviour until it's cleaned up by the individual
      filesystem maintainers.
      
      Exceptions:
      
       - affs already has identical copy & pasted code at the beginning of
         affs_put_super so no need to do it twice.
       - xfs does the right thing without it and I have changes pending for
         the xfs tree touching this are so I don't really need conflicts
         here..
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      8c85e125
  8. 05 6月, 2009 1 次提交
  9. 04 6月, 2009 1 次提交
  10. 25 5月, 2009 1 次提交
  11. 23 5月, 2009 1 次提交
  12. 18 5月, 2009 2 次提交
  13. 03 5月, 2009 1 次提交
  14. 02 5月, 2009 3 次提交
  15. 17 6月, 2009 1 次提交
  16. 26 4月, 2009 2 次提交
  17. 01 5月, 2009 1 次提交
    • T
      ext4: ext4_mark_recovery_complete() doesn't need to use lock_super · a63c9eb2
      Theodore Ts'o 提交于
      The function ext4_mark_recovery_complete() is called from two call
      paths: either (a) while mounting the filesystem, in which case there's
      no danger of any other CPU calling write_super() until the mount is
      completed, and (b) while remounting the filesystem read-write, in
      which case the fs core has already locked the superblock.  This also
      allows us to take out a very vile unlock_super()/lock_super() pair in
      ext4_remount().
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      a63c9eb2
  18. 26 4月, 2009 1 次提交
  19. 01 5月, 2009 1 次提交
    • T
      ext4: Avoid races caused by on-line resizing and SMP memory reordering · 8df9675f
      Theodore Ts'o 提交于
      Ext4's on-line resizing adds a new block group and then, only at the
      last step adjusts s_groups_count.  However, it's possible on SMP
      systems that another CPU could see the updated the s_group_count and
      not see the newly initialized data structures for the just-added block
      group.  For this reason, it's important to insert a SMP read barrier
      after reading s_groups_count and before reading any (for example) the
      new block group descriptors allowed by the increased value of
      s_groups_count.
      
      Unfortunately, we rather blatently violate this locking protocol
      documented in fs/ext4/resize.c.  Fortunately, (1) on-line resizes
      happen relatively rarely, and (2) it seems rare that the filesystem
      code will immediately try to use just-added block group before any
      memory ordering issues resolve themselves.  So apparently problems
      here are relatively hard to hit, since ext3 has been vulnerable to the
      same issue for years with no one apparently complaining.
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      8df9675f
  20. 02 5月, 2009 1 次提交
  21. 01 5月, 2009 2 次提交
    • T
      ext4: Fix and simplify s_dirt handling · 7234ab2a
      Theodore Ts'o 提交于
      The s_dirt flag wasn't completely handled correctly, but it didn't
      really matter when journalling was enabled.  It turns out that when
      ext4 runs without a journal, we don't clear s_dirt in places where we
      should have, with the result that the high-level write_super()
      function was writing the superblock when it wasn't necessary.
      
      So we fix this by making ext4_commit_super() clear the s_dirt flag,
      and removing many of the other places where s_dirt is manipulated.
      When journalling is enabled, the s_dirt flag might be left set more
      often, but s_dirt really doesn't matter when journalling is enabled.
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      7234ab2a
    • T
      ext4: Simplify ext4_commit_super()'s function signature · e2d67052
      Theodore Ts'o 提交于
      The ext4_commit_super() function took both a struct super_block * and
      a struct ext4_super_block *, but the struct ext4_super_block can be
      derived from the struct super_block.
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      e2d67052
  22. 25 4月, 2009 1 次提交
  23. 28 4月, 2009 1 次提交
    • T
      ext4: Fallback to vmalloc if kmalloc can't allocate s_flex_groups array · c5ca7c76
      Theodore Ts'o 提交于
      For very large filesystems, the s_flex_groups array can get quite big.
      For example, a filesystem that can be resized up to 16TB will have
      8192 flex groups (assuming the default flex_bg size of 16), so the
      array is 96k, which is *very* marginal for kmalloc().  On the other
      hand, a 160GB filesystem without the resize_inode feature will only
      require 960 bytes.  So we try to allocate the array first using
      kmalloc(), and if that fails, we'll try to use vmalloc() instead.
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      c5ca7c76
  24. 08 4月, 2009 1 次提交
  25. 28 3月, 2009 1 次提交
    • T
      ext4: Regularize mount options · 06705bff
      Theodore Ts'o 提交于
      Add support for using the mount options "barrier" and "nobarrier", and
      "auto_da_alloc" and "noauto_da_alloc", which is more consistent than
      "barrier=<0|1>" or "auto_da_alloc=<0|1>".  Most other ext3/ext4 mount
      options use the foo/nofoo naming convention.  We allow the old forms
      of these mount options for backwards compatibility.
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      06705bff
  26. 26 3月, 2009 2 次提交