> Yasunori Goto wrote: > > Hello. > > > > I chased the cause of following ext4 oops report which is tested on > > ia64 box. > > > > http://bugzilla.kernel.org/show_bug.cgi?id=12018 > > > > The cause is the size of s_mb_maxs array that is > > defined as "unsigned short" in ext4_sb_info structure. > > Unsigned short is too small. > > > > In this bug report, Li-san formatted with 64Kbyte block size like > > the following. Ia64 has 64Kbyte page size, then this > > block size is acceptable. > > > > # mkfs.ext4 -b 65536 /dev/md0 > > > > In this case, the maximum value of s_mb_maxs[] becomes > > (blocksize << 2) = 256K by the following code. > > > > 2482 int ext4_mb_init(struct super_block *sb, int needs_recovery) > > : > > : > > 2508 max = sb->s_blocksize << 2; <---- max becomes 0x40000. > > 2509 do { > > 2510 sbi->s_mb_offsets[i] = offset; > > 2511 sbi->s_mb_maxs[i] = max; <--- over flow!!! > > 2512 offset += 1 << (sb->s_blocksize_bits - i); > > 2513 max = max >> 1; > > 2514 i++; > > 2515 } while (i <= sb->s_blocksize_bits + 1); > > > > Then, some s_mb_maxs[] becomes 0 due to overflow. > > It is cause of this oops. The following patch is to fix it. > > Looks good to mee; and these lines before it: > > sbi->s_mb_maxs[0] = sb->s_blocksize << 3; > sbi->s_mb_offsets[0] = 0; > > mean that we would have a problem "even" on 8k blocks, yes? Oh, Yes. :-) Thanks. -- Yasunori Goto -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
