fix ext2 allocator overflows above 31 bit blocks
PATCH 1/1 fix ext2 allocator overflows above 31 bit blocks
If ext3 can do 16T, ext2 probably should be able to as well. There are still "int" block containers in the block allocation path that need to be fixed up.
Perhaps ext2 should get the ext2_fsblk_t/ext2_grpblk_t treatment as ext3 did, for clarity...
fs/ext2/balloc.c +4 -4
@@ -323,7 +323,7 @@ got_it:* bitmap, and then for any free bit if that fails. * This function also updates quota and i_blocks field. */ -int ext2_new_block (struct inode *inode,unsigned long goal, +unsigned long ext2_new_block (struct inode *inode,unsigned long goal,u32 *prealloc_count,u32 *prealloc_block,int *err) {struct buffer_head *bitmap_bh =NULL ;
@@ -332,8 +332,8 @@ int ext2_new_block(struct inode *inode,int group_no;/* i */ int ret_block;/* j */ int group_idx;/* k */ -int target_block;/* tmp */ -int block =0 ; +unsigned long target_block;/* tmp */ +unsigned long block =0 ;struct super_block *sb = inode->i_sb;struct ext2_sb_info *sbi =EXT2_SB (sb);struct ext2_super_block *es = sbi->s_es;
@@ -460,7 +460,7 @@ got_block: sbi->s_itb_per_group))ext2_error (sb,"ext2_new_block" ,"Allocating block in system zone - " -"block = %u" , target_block); +"block = %lu" , target_block);if (target_block >=le32_to_cpu (es->s_blocks_count)) { ext2_error (sb, "ext2_new_block",
fs/ext2/ext2.h +1 -1
@@ -91,7 +91,7 @@ static inline struct ext2_inode_info *EX/* balloc.c */ extern int ext2_bg_has_super (struct super_block *sb,int group);extern unsigned long ext2_bg_num_gdb (struct super_block *sb,int group); -extern int ext2_new_block (struct inode *,unsigned long , +extern unsigned long ext2_new_block (struct inode *,unsigned long ,__u32 *,__u32 *,int *);extern void ext2_free_blocks (struct inode *,unsigned long ,unsigned long );
fs/ext2/inode.c +3 -3
@@ -107,7 +107,7 @@ void ext2_discard_prealloc (struct inode#endif } -static int ext2_alloc_block (struct inode * inode,unsigned long goal,int *err) +static unsigned long ext2_alloc_block (struct inode * inode,unsigned long goal,int *err) {#ifdef EXT2FS_DEBUG static unsigned long alloc_hits, alloc_attempts;
@@ -425,13 +425,13 @@ static int ext2_alloc_branch(struct inodint n =0 ;int err;int i; -int parent =ext2_alloc_block (inode, goal, &err); +unsigned long parent =ext2_alloc_block (inode, goal, &err); branch[0 ].key =cpu_to_le32 (parent);if (parent)for (n =1 ; n < num; n++) {struct buffer_head *bh;/* Allocate the next block */ -int nr =ext2_alloc_block (inode, parent, &err); +unsigned long nr =ext2_alloc_block (inode, parent, &err);if (!nr)break ; branch[n].key =cpu_to_le32 (nr);
Quoted 3 lines · Eric Sandeen
If ext3 can do 16T, ext2 probably should be able to as well. There are still "int" block containers in the block allocation path that need to be fixed up.
Yeah, but who wants to do 16TB e2fsck on every boot? I think there needs to be some limits imposed for the sake of usability.
Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.
Quoted 7 lines · Andreas Dilger
Quoted 3 lines · Eric Sandeen
If ext3 can do 16T, ext2 probably should be able to as well. There are still "int" block containers in the block allocation path that need to be fixed up.
Yeah, but who wants to do 16TB e2fsck on every boot? I think there needs to be some limits imposed for the sake of usability.
I figure this is in the fine tradition of "enough rope to hang oneself"
If you have 16T of filesystem you probably know enough to not hang yourself this way.
*shrug*
It's a bug, today. If we need another change to limit ext2 to 500G or something, fine by me. :)
-Eric
Quoted 9 lines · Eric Sandeen
Quoted 7 lines · Andreas Dilger
Quoted 3 lines · Eric Sandeen
If ext3 can do 16T, ext2 probably should be able to as well. There are still "int" block containers in the block allocation path that need to be fixed up.
Yeah, but who wants to do 16TB e2fsck on every boot? I think there needs to be some limits imposed for the sake of usability.
Quoted 8 lines
I figure this is in the fine tradition of "enough rope to hang oneself"
If you have 16T of filesystem you probably know enough to not hang yourself this way.
*shrug*
It's a bug, today.
They are fixed in mm tree, as part of the patches which backports ext3 block reservation code to ext2. filesystem block numbers are all ext2_fsblk_t type(i.e. unsigned long)(see ext2_new_blocks()). Maybe need a round of thorough review to see if anything left, but I think what in mm tree looks good.
And those patches in mm tree also backports the ext3 best-effort allocates multiple blocks code (allocate multiple blocks within the block reservation window as much as possible), FYI.
Mingming
Quoted 8 lines
If we need another change to limit ext2 to 500G or something, fine by me. :)
(quoted diff) +0
-2-Eric -To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 8 lines · Mingming Cao
Quoted 1 line · Eric Sandeen
It's a bug, today.
They are fixed in mm tree, as part of the patches which backports ext3 block reservation code to ext2. filesystem block numbers are all
ext2_fsblk_ttype(i.e. unsigned long)(seeext2_new_blocks()). Maybe need a round of thorough review to see if anything left, but I think what in mm tree looks good.
Oh... oops. I didn't think to check mm, didn't expect to find those changes on ext2. Ok, I will double-check that against what I did.
Quoted 3 lines
And those patches in mm tree also backports the ext3 best-effort allocates multiple blocks code (allocate multiple blocks within the block reservation window as much as possible), FYI.
Ok, thanks Mingming!
-Eric