linux.git/fs/ext4/resize.c, branch v3.14

ext4: fix online resize with a non-standard blocks per group setting

2014-02-16T03:42:25+00:00

The set_flexbg_block_bitmap() function assumed that the number of
blocks in a blockgroup was sb->blocksize * 8, which is normally true,
but not always!  Use EXT4_BLOCKS_PER_GROUP(sb) instead, to fix block
bitmap corruption after:

mke2fs -t ext4 -g 3072 -i 4096 /dev/vdd 1G
mount -t ext4 /dev/vdd /vdd
resize2fs /dev/vdd 8G

Signed-off-by: "Theodore Ts'o" 
Reported-by: Jon Bernard 
Cc: stable@vger.kernel.org

ext4: fix online resize with very large inode tables

2014-02-16T02:33:13+00:00

If a file system has a large number of inodes per block group, all of
the metadata blocks in a flex_bg may be larger than what can fit in a
single block group.  Unfortunately, ext4_alloc_group_tables() in
resize.c was never tested to see if it would handle this case
correctly, and there were a large number of bugs which caused the
following sequence to result in a BUG_ON:

kernel bug at fs/ext4/resize.c:409!
   ...
call trace:
 [] ext4_flex_group_add+0x1448/0x1830
 [] ext4_resize_fs+0x7b2/0xe80
 [] ext4_ioctl+0xbf0/0xf00
 [] do_vfs_ioctl+0x2dd/0x4b0
 [] ? final_putname+0x22/0x50
 [] sys_ioctl+0x81/0xa0
 [] system_call_fastpath+0x16/0x1b
code: c8 4c 89 df e8 41 96 f8 ff 44 89 e8 49 01 c4 44 29 6d d4 0
rip  [] set_flexbg_block_bitmap+0x171/0x180


This can be reproduced with the following command sequence:

   mke2fs -t ext4 -i 4096 /dev/vdd 1G
   mount -t ext4 /dev/vdd /vdd
   resize2fs /dev/vdd 8G

To fix this, we need to make sure the right thing happens when a block
group's inode table straddles two block groups, which means the
following bugs had to be fixed:

1) Not clearing the BLOCK_UNINIT flag in the second block group in
   ext4_alloc_group_tables --- the was proximate cause of the BUG_ON.

2) Incorrectly determining how many block groups contained contiguous
   free blocks in ext4_alloc_group_tables().

3) Incorrectly setting the start of the next block range to be marked
   in use after a discontinuity in setup_new_flex_group_blocks().

Signed-off-by: "Theodore Ts'o" 
Cc: stable@vger.kernel.org

ext4: fix corruption when online resizing a fs with 1K block size

2013-07-01T12:12:08+00:00

Subtracting the number of the first data block places the superblock
backups one block too early, corrupting the file system. When the block
size is larger than 1K, the first data block is 0, so the subtraction
has no effect and no corruption occurs.

Signed-off-by: Maarten ter Huurne 
Signed-off-by: "Theodore Ts'o" 
Reviewed-by: Jan Kara 
CC: stable@vger.kernel.org

ext4: delete unused variables

2013-06-17T12:56:26+00:00

This patch removed several unused variables.

Signed-off-by: Jon Ernst 
Signed-off-by: "Theodore Ts'o"

ext4: verify group number in verify_group_input() before using it

2013-06-06T15:14:31+00:00

Check the group number for sanity earilier, before calling routines
such as ext4_bg_has_super() or ext4_group_overhead_blocks().

Reported-by: Jonathan Salwan 
Signed-off-by: "Theodore Ts'o"

ext4: add check for inodes_count overflow in new resize ioctl

2013-04-22T02:56:32+00:00

Addresses-Red-Hat-Bugzilla: #913245

Reported-by: Eric Sandeen 
Signed-off-by: "Theodore Ts'o" 
Reviewed-by: Carlos Maiolino 
Cc: stable@vger.kernel.org

ext4: fix online resizing for ext3-compat file systems

2013-04-22T00:19:43+00:00

Commit fb0a387dcdc restricts block allocations for indirect-mapped
files to block groups less than s_blockfile_groups.  However, the
online resizing code wasn't setting s_blockfile_groups, so the newly
added block groups were not available for non-extent mapped files.

Reported-by: Eric Sandeen 
Signed-off-by: "Theodore Ts'o" 
Cc: stable@vger.kernel.org

ext4: introduce ext4_get_group_number()

2013-04-04T03:32:34+00:00

Currently on many places in ext4 we're using
ext4_get_group_no_and_offset() even though we're only interested in
knowing the block group of the particular block, not the offset within
the block group so we can use more efficient way to compute block
group.

This patch introduces ext4_get_group_number() which computes block
group for a given block much more efficiently. Use this function
instead of ext4_get_group_no_and_offset() everywhere where we're only
interested in knowing the block group.

Signed-off-by: Lukas Czerner 
Signed-off-by: "Theodore Ts'o"

ext4: use atomic64_t for the per-flexbg free_clusters count

2013-03-12T03:39:59+00:00

A user who was using a 8TB+ file system and with a very large flexbg
size (> 65536) could cause the atomic_t used in the struct flex_groups
to overflow.  This was detected by PaX security patchset:

http://forums.grsecurity.net/viewtopic.php?f=3&t=3289&p=12551#p12551

This bug was introduced in commit 9f24e4208f7e, so it's been around
since 2.6.30.  :-(

Fix this by using an atomic64_t for struct orlav_stats's
free_clusters.

Signed-off-by: "Theodore Ts'o" 
Reviewed-by: Lukas Czerner 
Cc: stable@vger.kernel.org

ext4: convert number of blocks to clusters properly

2013-03-02T22:18:58+00:00

We're using macro EXT4_B2C() to convert number of blocks to number of
clusters for bigalloc file systems.  However, we should be using
EXT4_NUM_B2C().

Signed-off-by: Lukas Czerner 
Signed-off-by: "Theodore Ts'o" 
Cc: stable@vger.kernel.org