]> git.kernelconcepts.de Git - karo-tx-linux.git/commit
ext4: fix bb_prealloc_list corruption due to wrong group locking
authorEric Sandeen <sandeen@redhat.com>
Tue, 2 Jun 2009 12:09:17 +0000 (08:09 -0400)
committerGreg Kroah-Hartman <gregkh@suse.de>
Fri, 12 Jun 2009 03:01:40 +0000 (20:01 -0700)
commita529e6f6579e30c3e9a18dc30a87a62be169acde
tree6aad5154811932fd182e629aefd7e76ea67635c2
parent45658de1b35a2711610037d6a06b50a2dd4485fa
ext4: fix bb_prealloc_list corruption due to wrong group locking

(cherry-picked from commit d33a1976fbee1ee321d6f014333d8f03a39d526c)

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: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
fs/ext4/mballoc.c