[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <49BAD6D9.3010505@redhat.com>
Date: Fri, 13 Mar 2009 16:57:45 -0500
From: Eric Sandeen <sandeen@...hat.com>
To: ext4 development <linux-ext4@...r.kernel.org>
Subject: [PATCH] fix bb_prealloc_list corruption due to wrong group locking
This is for Red Hat bug 490026,
EXT4 panic, list corruption in ext4_mb_new_inode_pa
(this was on backported ext4 from 2.6.29)
We hit a BUG() in __list_add from ext4_mb_new_inode_pa()
because the list head pointed to a removed item:
list_add corruption. next->prev should be ffff81042f2fe158,
but was 0000000000200200
(0000000000200200 is LIST_POISON2, set when the item is deleted)
ext4_lock_group(sb, group) is supposed to protect this list for
each group, and a common code flow is 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 its critical that we get the right group number back for
this pa->pa_pstart block.
however, ext4_mb_put_pa passes in (pa->pa_pstart - 1) with a
comment, "-1 is to protect from crossing allocation group"
Other list-manipulators do not use the "-1" so we have the
potential to lock the wrong group and race. Given how the
ext4_get_group_no_and_offset() function works, it doesn't seem
to me that the subtraction is correct.
I've not been able to reproduce the bug, so this is by inspection.
Signed-off-by: Eric Sandeen <sandeen@...hat.com>
---
Index: linux-2.6/fs/ext4/mballoc.c
===================================================================
--- linux-2.6.orig/fs/ext4/mballoc.c
+++ linux-2.6/fs/ext4/mballoc.c
@@ -3603,8 +3603,7 @@ static void ext4_mb_put_pa(struct ext4_a
pa->pa_deleted = 1;
spin_unlock(&pa->pa_lock);
- /* -1 is to protect from crossing allocation group */
- ext4_get_group_no_and_offset(sb, pa->pa_pstart - 1, &grp, NULL);
+ ext4_get_group_no_and_offset(sb, pa->pa_pstart, &grp, NULL);
/*
* possible race:
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists