1. 21 Feb, 2012 3 commits
    • Zheng Liu's avatar
      ext4: format flag in dx_probe() · 9ee49302
      Zheng Liu authored
      
      Fix ext4_warning format flag in dx_probe().
      
      CC: "Theodore Ts'o" <tytso@mit.edu>
      Signed-off-by: default avatarZheng Liu <wenqing.lz@taobao.com>
      Signed-off-by: default avatar"Theodore Ts'o" <tytso@mit.edu>
      9ee49302
    • Eric Sandeen's avatar
      ext4: avoid deadlock on sync-mounted FS w/o journal · c1bb05a6
      Eric Sandeen authored
      Processes hang forever on a sync-mounted ext2 file system that
      is mounted with the ext4 module (default in Fedora 16).
      
      I can reproduce this reliably by mounting an ext2 partition with
      "-o sync" and opening a new file an that partition with vim. vim
      will hang in "D" state forever.  The same happens on ext4 without
      a journal.
      
      I am attaching a small patch here that solves this issue for me.
      In the sync mounted case without a journal,
      ext4_handle_dirty_metadata() may call sync_dirty_buffer(), which
      can't be called with buffer lock held.
      
      Also move mb_cache_entry_release inside lock to avoid race
      fixed previously by 8a2bfdcb ext[34]: EA block reference count racing fix
      Note too that ext2 fixed this same problem in 2006 with
      b2f49033
      
       [PATCH] fix deadlock in ext2
      
      Signed-off-by: Martin.Wilck@ts.fujitsu.com
      [sandeen@redhat.com: move mb_cache_entry_release before unlock, edit commit msg]
      Signed-off-by: default avatarEric Sandeen <sandeen@redhat.com>
      Signed-off-by: default avatar"Theodore Ts'o" <tytso@mit.edu>
      c1bb05a6
    • Lukas Czerner's avatar
      ext4: fix resize when resizing within single group · a0ade1de
      Lukas Czerner authored
      
      When resizing file system in the way that the new size of the file
      system is still in the same group (no new groups are added), then we can
      hit a BUG_ON in ext4_alloc_group_tables()
      
      BUG_ON(flex_gd->count == 0 || group_data == NULL);
      
      because flex_gd->count is zero. The reason is the missing check for such
      case, so the code always extend the last group fully and then attempt to
      add more groups, but at that time n_blocks_count is actually smaller
      than o_blocks_count.
      
      It can be easily reproduced like this:
      
      mkfs.ext4 -b 4096 /dev/sda 30M
      mount /dev/sda /mnt/test
      resize2fs /dev/sda 50M
      
      Fix this by checking whether the resize happens within the singe group
      and only add that many blocks into the last group to satisfy user
      request. Then o_blocks_count == n_blocks_count and the resize will exit
      successfully without and attempt to add more groups into the fs.
      
      Also fix mixing together block number and blocks count which might be
      confusing and can easily lead to off-by-one errors (but it is actually
      not the case here since the two occurrence of this mix-up will cancel
      each other).
      Signed-off-by: default avatarLukas Czerner <lczerner@redhat.com>
      Reported-by: default avatarMilan Broz <mbroz@redhat.com>
      Reviewed-by: default avatarEric Sandeen <sandeen@redhat.com>
      Signed-off-by: default avatar"Theodore Ts'o" <tytso@mit.edu>
      a0ade1de
  2. 20 Feb, 2012 18 commits
  3. 07 Feb, 2012 1 commit
  4. 31 Jan, 2012 4 commits
  5. 30 Jan, 2012 14 commits