On 32-bit platform, the value of n_blcoks_count may be wrong during the
file system is resized to size larger than 2^32 blocks. This may caused
the superblock being corrupted with zero blocks count.
Signed-off-by: Jerry Lee <[email protected]>
---
fs/ext4/resize.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletions(-)
diff --git a/fs/ext4/resize.c b/fs/ext4/resize.c
index c3ed902..035cd3f 100644
--- a/fs/ext4/resize.c
+++ b/fs/ext4/resize.c
@@ -1927,7 +1927,8 @@ int ext4_resize_fs(struct super_block *sb,
ext4_fsblk_t n_blocks_count)
n_desc_blocks = o_desc_blocks +
le16_to_cpu(es->s_reserved_gdt_blocks);
n_group = n_desc_blocks * EXT4_DESC_PER_BLOCK(sb);
- n_blocks_count = n_group * EXT4_BLOCKS_PER_GROUP(sb);
+ n_blocks_count = (ext4_fsblk_t)n_group *
+ EXT4_BLOCKS_PER_GROUP(sb);
n_group--; /* set to last group number */
}
On Fri, Jul 28, 2017 at 02:23:55PM +0800, Jerry Lee wrote:
> On 32-bit platform, the value of n_blcoks_count may be wrong during the
> file system is resized to size larger than 2^32 blocks. This may caused
> the superblock being corrupted with zero blocks count.
>
> Signed-off-by: Jerry Lee <[email protected]>
Thanks, applied.
- Ted