ext4: fix ext4_mb_mark_bb() with flex_bg with fast_commit
authorRitesh Harjani <riteshh@linux.ibm.com>
Wed, 16 Feb 2022 07:02:44 +0000 (12:32 +0530)
committerTheodore Ts'o <tytso@mit.edu>
Sat, 26 Feb 2022 02:34:56 +0000 (21:34 -0500)
commitbfdc502a4a4c058bf4cbb1df0c297761d528f54d
treea89a0ca75dc97385756d34f0f7ff4cf93329b513
parenta5c0e2fdf7cea535ba03259894dc184e5a4c2800
ext4: fix ext4_mb_mark_bb() with flex_bg with fast_commit

In case of flex_bg feature (which is by default enabled), extents for
any given inode might span across blocks from two different block group.
ext4_mb_mark_bb() only reads the buffer_head of block bitmap once for the
starting block group, but it fails to read it again when the extent length
boundary overflows to another block group. Then in this below loop it
accesses memory beyond the block group bitmap buffer_head and results
into a data abort.

for (i = 0; i < clen; i++)
if (!mb_test_bit(blkoff + i, bitmap_bh->b_data) == !state)
already++;

This patch adds this functionality for checking block group boundary in
ext4_mb_mark_bb() and update the buffer_head(bitmap_bh) for every different
block group.

w/o this patch, I was easily able to hit a data access abort using Power platform.

<...>
[   74.327662] EXT4-fs error (device loop3): ext4_mb_generate_buddy:1141: group 11, block bitmap and bg descriptor inconsistent: 21248 vs 23294 free clusters
[   74.533214] EXT4-fs (loop3): shut down requested (2)
[   74.536705] Aborting journal on device loop3-8.
[   74.702705] BUG: Unable to handle kernel data access on read at 0xc00000005e980000
[   74.703727] Faulting instruction address: 0xc0000000007bffb8
cpu 0xd: Vector: 300 (Data Access) at [c000000015db7060]
    pc: c0000000007bffb8: ext4_mb_mark_bb+0x198/0x5a0
    lr: c0000000007bfeec: ext4_mb_mark_bb+0xcc/0x5a0
    sp: c000000015db7300
   msr: 800000000280b033
   dar: c00000005e980000
 dsisr: 40000000
  current = 0xc000000027af6880
  paca    = 0xc00000003ffd5200   irqmask: 0x03   irq_happened: 0x01
    pid   = 5167, comm = mount
<...>
enter ? for help
[c000000015db7380c000000000782708 ext4_ext_clear_bb+0x378/0x410
[c000000015db7400c000000000813f14 ext4_fc_replay+0x1794/0x2000
[c000000015db7580c000000000833f7c do_one_pass+0xe9c/0x12a0
[c000000015db7710c000000000834504 jbd2_journal_recover+0x184/0x2d0
[c000000015db77c0c000000000841398 jbd2_journal_load+0x188/0x4a0
[c000000015db7880c000000000804de8 ext4_fill_super+0x2638/0x3e10
[c000000015db7a40c0000000005f8404 get_tree_bdev+0x2b4/0x350
[c000000015db7ae0c0000000007ef058 ext4_get_tree+0x28/0x40
[c000000015db7b00c0000000005f6344 vfs_get_tree+0x44/0x100
[c000000015db7b70c00000000063c408 path_mount+0xdd8/0xe70
[c000000015db7c40c00000000063c8f0 sys_mount+0x450/0x550
[c000000015db7d50c000000000035770 system_call_exception+0x4a0/0x4e0
[c000000015db7e10c00000000000c74c system_call_common+0xec/0x250

Signed-off-by: Ritesh Harjani <riteshh@linux.ibm.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Link: https://lore.kernel.org/r/2609bc8f66fc15870616ee416a18a3d392a209c4.1644992609.git.riteshh@linux.ibm.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
fs/ext4/mballoc.c