1. 16 Mar, 2009 1 commit
    • Eric Sandeen's avatar
      ext4: fix bb_prealloc_list corruption due to wrong group locking · d33a1976
      Eric Sandeen authored
      
      
      This is for Red Hat bug 490026: EXT4 panic, list corruption in
      ext4_mb_new_inode_pa
      
      ext4_lock_group(sb, group) is supposed to protect this list for
      each group, and a common code flow to remove an album is like
      this:
      
          ext4_get_group_no_and_offset(sb, pa->pa_pstart, &grp, NULL);
          ext4_lock_group(sb, grp);
          list_del(&pa->pa_group_list);
          ext4_unlock_group(sb, grp);
      
      so it's critical that we get the right group number back for
      this prealloc context, to lock the right group (the one 
      associated with this pa) and prevent concurrent list manipulation.
      
      however, ext4_mb_put_pa() passes in (pa->pa_pstart - 1) with a 
      comment, "-1 is to protect from crossing allocation group".
      
      This makes sense for the group_pa, where pa_pstart is advanced
      by the length which has been used (in ext4_mb_release_context()),
      and when the entire length has been used, pa_pstart has been
      advanced to the first block of the next group.
      
      However, for inode_pa, pa_pstart is never advanced; it's just
      set once to the first block in the group and not moved after
      that.  So in this case, if we subtract one in ext4_mb_put_pa(),
      we are actually locking the *previous* group, and opening the
      race with the other threads which do not subtract off the extra
      block.
      Signed-off-by: default avatarEric Sandeen <sandeen@redhat.com>
      Signed-off-by: default avatar"Theodore Ts'o" <tytso@mit.edu>
      d33a1976
  2. 14 Mar, 2009 1 commit
    • Eric Sandeen's avatar
      ext4: fix bogus BUG_ONs in in mballoc code · 8d03c7a0
      Eric Sandeen authored
      
      
      Thiemo Nagel reported that:
      
      # dd if=/dev/zero of=image.ext4 bs=1M count=2
      # mkfs.ext4 -v -F -b 1024 -m 0 -g 512 -G 4 -I 128 -N 1 \
        -O large_file,dir_index,flex_bg,extent,sparse_super image.ext4
      # mount -o loop image.ext4 mnt/
      # dd if=/dev/zero of=mnt/file
      
      oopsed, with a BUG_ON in ext4_mb_normalize_request because
      size == EXT4_BLOCKS_PER_GROUP
      
      It appears to me (esp. after talking to Andreas) that the BUG_ON
      is bogus; a request of exactly EXT4_BLOCKS_PER_GROUP should
      be allowed, though larger sizes do indicate a problem.
      
      Fix that an another (apparently rare) codepath with a similar check.
      Reported-by: default avatarThiemo Nagel <thiemo.nagel@ph.tum.de>
      Signed-off-by: default avatarEric Sandeen <sandeen@redhat.com>
      Signed-off-by: default avatar"Theodore Ts'o" <tytso@mit.edu>
      8d03c7a0
  3. 12 Mar, 2009 1 commit
  4. 10 Mar, 2009 1 commit
    • Eric Sandeen's avatar
      ext4: fix header check in ext4_ext_search_right() for deep extent trees. · 395a87bf
      Eric Sandeen authored
      The ext4_ext_search_right() function is confusing; it uses a
      "depth" variable which is 0 at the root and maximum at the leaves, 
      but the on-disk metadata uses a "depth" (actually eh_depth) which
      is opposite: maximum at the root, and 0 at the leaves.
      
      The ext4_ext_check_header() function is given a depth and checks
      the header agaisnt that depth; it expects the on-disk semantics,
      but we are giving it the opposite in the while loop in this 
      function.  We should be giving it the on-disk notion of "depth"
      which we can get from (p_depth - depth) - and if you look, the last
      (more commonly hit) call to ext4_ext_check_header() does just this.
      
      Sending in the wrong depth results in (incorrect) messages
      about corruption:
      
      EXT4-fs error (device sdb1): ext4_ext_search_right: bad header
      in inode #2621457: unexpected eh_depth - magic f30a, entries 340,
      max 340(0), depth 1(2)
      
      http://bugzilla.kernel.org/show_bug.cgi?id=12821
      
      Reported-by: default avatarDavid Dindorp <ddi@dubex.dk>
      Signed-off-by: default avatarEric Sandeen <sandeen@redhat.com>
      Signed-off-by: default avatar"Theodore Ts'o" <tytso@mit.edu>
      395a87bf
  5. 12 Mar, 2009 33 commits
  6. 11 Mar, 2009 3 commits