1. 30 1月, 2013 1 次提交
  2. 29 1月, 2013 10 次提交
  3. 28 1月, 2013 6 次提交
  4. 25 1月, 2013 2 次提交
  5. 17 1月, 2013 1 次提交
  6. 13 1月, 2013 4 次提交
    • T
      ext4: trigger the lazy inode table initialization after resize · 7f511862
      Theodore Ts'o 提交于
      After we have finished extending the file system, we need to trigger a
      the lazy inode table thread to zero out the inode tables.
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      7f511862
    • E
      ext4: check bh in ext4_read_block_bitmap() · 15b49132
      Eryu Guan 提交于
      Validate the bh pointer before using it, since
      ext4_read_block_bitmap_nowait() might return NULL.
      
      I've seen this in fsfuzz testing.
      
       EXT4-fs error (device loop0): ext4_read_block_bitmap_nowait:385: comm touch: Cannot get buffer for block bitmap - block_group = 0, block_bitmap = 3925999616
       BUG: unable to handle kernel NULL pointer dereference at           (null)
       IP: [<ffffffff8121de25>] ext4_wait_block_bitmap+0x25/0xe0
       ...
       Call Trace:
        [<ffffffff8121e1e5>] ext4_read_block_bitmap+0x35/0x60
        [<ffffffff8125e9c6>] ext4_free_blocks+0x236/0xb80
        [<ffffffff811d0d36>] ? __getblk+0x36/0x70
        [<ffffffff811d0a5f>] ? __find_get_block+0x8f/0x210
        [<ffffffff81191ef3>] ? kmem_cache_free+0x33/0x140
        [<ffffffff812678e5>] ext4_xattr_release_block+0x1b5/0x1d0
        [<ffffffff812679be>] ext4_xattr_delete_inode+0xbe/0x100
        [<ffffffff81222a7c>] ext4_free_inode+0x7c/0x4d0
        [<ffffffff812277b8>] ? ext4_mark_inode_dirty+0x88/0x230
        [<ffffffff8122993c>] ext4_evict_inode+0x32c/0x490
        [<ffffffff811b8cd7>] evict+0xa7/0x1c0
        [<ffffffff811b8ed3>] iput_final+0xe3/0x170
        [<ffffffff811b8f9e>] iput+0x3e/0x50
        [<ffffffff812316fd>] ext4_add_nondir+0x4d/0x90
        [<ffffffff81231d0b>] ext4_create+0xeb/0x170
        [<ffffffff811aae9c>] vfs_create+0xac/0xd0
        [<ffffffff811ac845>] lookup_open+0x185/0x1c0
        [<ffffffff8129e3b9>] ? selinux_inode_permission+0xa9/0x170
        [<ffffffff811acb54>] do_last+0x2d4/0x7a0
        [<ffffffff811af743>] path_openat+0xb3/0x480
        [<ffffffff8116a8a1>] ? handle_mm_fault+0x251/0x3b0
        [<ffffffff811afc49>] do_filp_open+0x49/0xa0
        [<ffffffff811bbaad>] ? __alloc_fd+0xdd/0x150
        [<ffffffff8119da28>] do_sys_open+0x108/0x1f0
        [<ffffffff8119db51>] sys_open+0x21/0x30
        [<ffffffff81618959>] system_call_fastpath+0x16/0x1b
      
      Also fix comment for ext4_read_block_bitmap_nowait()
      Signed-off-by: NEryu Guan <guaneryu@gmail.com>
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      Cc: stable@vger.kernel.org
      15b49132
    • W
      ext4: use unlikely to improve the efficiency of the kernel · aebf0243
      Wang Shilong 提交于
      Because the function 'sb_getblk' seldomly fails to return NULL
      value,it will be better to use 'unlikely' to optimize it.
      Signed-off-by: NWang Shilong <wangsl-fnst@cn.fujitsu.com>
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      aebf0243
    • T
      ext4: return ENOMEM if sb_getblk() fails · 860d21e2
      Theodore Ts'o 提交于
      The only reason for sb_getblk() failing is if it can't allocate the
      buffer_head.  So ENOMEM is more appropriate than EIO.  In addition,
      make sure that the file system is marked as being inconsistent if
      sb_getblk() fails.
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      Cc: stable@vger.kernel.org
      860d21e2
  7. 07 1月, 2013 3 次提交
  8. 27 12月, 2012 2 次提交
    • T
      ext4: avoid hang when mounting non-journal filesystems with orphan list · 0e9a9a1a
      Theodore Ts'o 提交于
      When trying to mount a file system which does not contain a journal,
      but which does have a orphan list containing an inode which needs to
      be truncated, the mount call with hang forever in
      ext4_orphan_cleanup() because ext4_orphan_del() will return
      immediately without removing the inode from the orphan list, leading
      to an uninterruptible loop in kernel code which will busy out one of
      the CPU's on the system.
      
      This can be trivially reproduced by trying to mount the file system
      found in tests/f_orphan_extents_inode/image.gz from the e2fsprogs
      source tree.  If a malicious user were to put this on a USB stick, and
      mount it on a Linux desktop which has automatic mounts enabled, this
      could be considered a potential denial of service attack.  (Not a big
      deal in practice, but professional paranoids worry about such things,
      and have even been known to allocate CVE numbers for such problems.)
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      Reviewed-by: NZheng Liu <wenqing.lz@taobao.com>
      Cc: stable@vger.kernel.org
      0e9a9a1a
    • T
      ext4: lock i_mutex when truncating orphan inodes · 721e3eba
      Theodore Ts'o 提交于
      Commit c278531d added a warning when ext4_flush_unwritten_io() is
      called without i_mutex being taken.  It had previously not been taken
      during orphan cleanup since races weren't possible at that point in
      the mount process, but as a result of this c278531d, we will now see
      a kernel WARN_ON in this case.  Take the i_mutex in
      ext4_orphan_cleanup() to suppress this warning.
      Reported-by: NAlexander Beregalov <a.beregalov@gmail.com>
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      Reviewed-by: NZheng Liu <wenqing.lz@taobao.com>
      Cc: stable@vger.kernel.org
      721e3eba
  9. 26 12月, 2012 6 次提交
  10. 20 12月, 2012 1 次提交
  11. 18 12月, 2012 1 次提交
  12. 17 12月, 2012 1 次提交
  13. 11 12月, 2012 2 次提交
    • T
      ext4: zero out inline data using memset() instead of empty_zero_page · bd9926e8
      Theodore Ts'o 提交于
      Not all architectures (in particular, sparc64) have empty_zero_page.
      So instead of copying from empty_zero_page, use memset to clear the
      inline data by signalling to ext4_xattr_set_entry() via a magic
      pointer value, EXT4_ZERO_ATTR_VALUE, which is defined by casting -1 to
      a pointer.
      
      This fixes a build failure on sparc64, and the memset() should be more
      efficient than using memcpy() anyway.
      Signed-off-by: NTao Ma <boyu.mt@taobao.com>
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      bd9926e8
    • C
      ext4: ensure Inode flags consistency are checked at build time · 9a4c8019
      Carlos Maiolino 提交于
      
      Flags being used by atomic operations in inode flags (e.g.
      ext4_test_inode_flag(), should be consistent with that actually stored
      in inodes, i.e.: EXT4_XXX_FL.
      
      It ensures that this consistency is checked at build-time, not at
      run-time.
      
      Currently, the flags consistency are being checked at run-time, but,
      there is no real reason to not do a build-time check instead of a
      run-time check. The code is comparing macro defined values with enum
      type variables, where both are constants, so, there is no problem in
      comparing constants at build-time.
      
      enum variables are treated as constants by the C compiler, according
      to the C99 specs (see www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf 
      sec. 6.2.5, item 16), so, there is no real problem in comparing an
      enumeration type at build time
      Signed-off-by: NCarlos Maiolino <cmaiolino@redhat.com>
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      9a4c8019