lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <47B4353E.306@bull.net> Date: Thu, 14 Feb 2008 13:34:06 +0100 From: Valerie Clement <valerie.clement@...l.net> To: Andreas Dilger <adilger@....com> Cc: linux-ext4 <linux-ext4@...r.kernel.org> Subject: Re: [PATCH] ext4: Fix kernel BUG at fs/ext4/mballoc.c:910! Andreas Dilger wrote: > On Feb 13, 2008 18:19 +0100, Valerie Clement wrote: >> From: Valerie Clement <valerie.clement@...l.net> >> >> With the flex_bg feature enabled, a large file creation oopses the >> kernel. >> The BUG_ON is: >> BUG_ON(len >= EXT4_BLOCKS_PER_GROUP(sb)); >> >> As the allocation of the bitmaps and the inode table can be done >> outside the block group with flex_bg, this allows to allocate up to >> EXT4_BLOCKS_PER_GROUP blocks in a group. > > Caution is needed here. In the past we were limited to BLOCKS_PER_GROUP() > blocks per extent (32768 blocks at most, regardless of blocksize I think) > but now an extent might be larger. > > Can you please verify that the extent-length limits for "initialized" vs. > "uninitialized" extents are being hit so that extents don't accidentally > grow to be > 32768 blocks long and suddenly get marked as short uninitialized > extents. > > Note that the assertion can still be hit if groups are created with fewer > blocks, or with blocksize < 4096. For example, if we have blocksize = 1024 > this gives BLOCKS_PER_GROUP=8192, but an extent can be up to 32768 blocks. > > I think the right assertion is now: > > BUG_ON(len > EXT4_INIT_MAX_LEN); > > if FLEX_BG is active. I'm not sure if we want to keep the stricter assertion: > > BUG_ON(len > EXT4_HAS_INCOMPAT_FEATURE_FLEX_BG(sb) ? EXT4_INIT_MAX_LEN : > EXT4_BLOCKS_PER_GROUP(sb)); > > but it might be worthwhile at least initially, and I don't think the CPU cost > is very high. I agree. I'll do the changes. > >> diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c >> index b0f84b4..0275150 100644 >> --- a/fs/ext4/mballoc.c >> +++ b/fs/ext4/mballoc.c >> @@ -907,7 +907,7 @@ static void ext4_mb_mark_free_simple(struct super_block *sb, >> unsigned short chunk; >> unsigned short border; >> >> - BUG_ON(len >= EXT4_BLOCKS_PER_GROUP(sb)); >> + BUG_ON(len > EXT4_BLOCKS_PER_GROUP(sb)); >> >> border = 2 << sb->s_blocksize_bits; >> >> @@ -3286,7 +3286,7 @@ static void ext4_mb_normalize_request(struct ext4_allocation_context *ac, >> } >> BUG_ON(start + size <= ac->ac_o_ex.fe_logical && >> start > ac->ac_o_ex.fe_logical); >> - BUG_ON(size <= 0 || size >= EXT4_BLOCKS_PER_GROUP(ac->ac_sb)); >> + BUG_ON(size <= 0 || size > EXT4_BLOCKS_PER_GROUP(ac->ac_sb)); > > Please separate this into two BUG_ON() statements, so it is clear which > one is being hit. OK. Thanks for review, Valerie - 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