[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <201002091827.o19IRiC5018525@demeter.kernel.org>
Date: Tue, 9 Feb 2010 18:27:44 GMT
From: bugzilla-daemon@...zilla.kernel.org
To: linux-ext4@...r.kernel.org
Subject: [Bug 15231] kernel BUG at fs/ext4/inode.c:1852!
http://bugzilla.kernel.org/show_bug.cgi?id=15231
--- Comment #8 from Theodore Tso <tytso@....edu> 2010-02-09 18:27:22 ---
Well, the BUG_ON getting tripped as reported in comment #1 in this bug is:
BUG_ON(mdblocks < EXT4_I(inode)->i_reserved_meta_blocks);
... and the commit 39bc680a does mess with how i_reserved_meta_blocks is
calculated.
@@ -1836,10 +1834,11 @@ repeat:
}
return -ENOSPC;
}
+ spin_lock(&EXT4_I(inode)->i_block_reservation_lock);
EXT4_I(inode)->i_reserved_data_blocks += nrblocks;
- EXT4_I(inode)->i_reserved_meta_blocks = mdblocks;
-
+ EXT4_I(inode)->i_reserved_meta_blocks += md_needed;
spin_unlock(&EXT4_I(inode)->i_block_reservation_lock);
+
return 0; /* success */
I'm going to need to go back and see whether I screwed up earlier and blamed
the wrong commit earlier, or whether that commit was implicated in some other
regression. However, given the claimed regression between 2.6.32.2 and
2.6.32.7, and given that commit 39bc680a was applied between 2.6.32.2 and
2.6.32.3, at the very least we should try backing out 39bc680a and seeing
whether that makes Franco's problem go away.
--
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
--
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