[GH-ISSUE #70] ext2fs: block/inode allocation panics 'ext2fs_alloccg: map corrupted' when a group fills while bread sleeps #62

New issue

Closed

opened 2026-11-03 22:03:34 -07:00 by gitea-mirror · 1 comment

gitea-mirror commented

2026-11-03 22:03:34 -07:00

Owner

Originally created by @raynorpat on GitHub (Oct 20, 2026).
Original GitHub issue: https://github.com/RhapsodiOS/RhapsodiOS/issues/70

Symptom

With several processes writing to an ext2 volume until a block group runs out of space, the kernel panics:

panic: ext2fs_alloccg: map corrupted

Both panic dumps show the chosen group with nbfree = 0 and a block bitmap that is all 0xff. The volume itself is fine: the group really is full.

Reproduce

vm/work/ext2-sync/race.sh: 8 concurrent 2 MB writers on a 1K-block ext2 volume (WSL mke2fs -t ext2 -r 1 -O none,filetype,sparse_super -I 128 -b 1024) so that one block group fills up. It panicked within the first loops. The stress suite's concurrent load (ab.sh) hit it in round 3.

Cause

ext2fs_alloccg (bsd/ext2fs/ext2fs_alloc.c ~378) checks the group's nbfree and then breads the bitmap. bread can sleep on the bitmap buffer while another allocator, doing its synchronous bitmap write, takes the group's last free blocks. On return the bitmap has no free bit, and the scan reports "map corrupted". ext2fs_nodealloccg has the same pattern for inodes.

Fix

d95feb4e2: re-check nbfree/nifree after the bread and return "no space in this group", so the caller tries the next group. Merged into ffs-perf in 4fd6d07b6.

Verified:

race.sh: 20 of 20 loops clean.
Concurrent mmap/runtests -n 4 on ext2, UFS and FAT16: 18/18 PASS each.
ext2_mmap_truncate_test and make check-mmap pass.
WSL e2fsck -fn is clean after every run.

Found while investigating an ext2 mmap sync read-back failure under concurrent load. That failure itself was the QEMU FSAVE problem filed separately.

Originally created by @raynorpat on GitHub (Oct 20, 2026). Original GitHub issue: https://github.com/RhapsodiOS/RhapsodiOS/issues/70 ## Symptom With several processes writing to an ext2 volume until a block group runs out of space, the kernel panics: ``` panic: ext2fs_alloccg: map corrupted ``` Both panic dumps show the chosen group with `nbfree = 0` and a block bitmap that is all `0xff`. The volume itself is fine: the group really is full. ## Reproduce `vm/work/ext2-sync/race.sh`: 8 concurrent 2 MB writers on a 1K-block ext2 volume (WSL `mke2fs -t ext2 -r 1 -O none,filetype,sparse_super -I 128 -b 1024`) so that one block group fills up. It panicked within the first loops. The stress suite's concurrent load (`ab.sh`) hit it in round 3. ## Cause `ext2fs_alloccg` (`bsd/ext2fs/ext2fs_alloc.c` ~378) checks the group's `nbfree` and then `bread`s the bitmap. `bread` can sleep on the bitmap buffer while another allocator, doing its synchronous bitmap write, takes the group's last free blocks. On return the bitmap has no free bit, and the scan reports "map corrupted". `ext2fs_nodealloccg` has the same pattern for inodes. ## Fix d95feb4e2: re-check `nbfree`/`nifree` after the `bread` and return "no space in this group", so the caller tries the next group. Merged into ffs-perf in 4fd6d07b6. Verified: - `race.sh`: 20 of 20 loops clean. - Concurrent `mmap/runtests -n 4` on ext2, UFS and FAT16: 18/18 PASS each. - `ext2_mmap_truncate_test` and `make check-mmap` pass. - WSL `e2fsck -fn` is clean after every run. Found while investigating an ext2 `mmap sync` read-back failure under concurrent load. That failure itself was the QEMU FSAVE problem filed separately.

gitea-mirror closed this issue

2026-11-03 22:03:34 -07:00

gitea-mirror commented

2026-11-03 22:03:36 -07:00

Author

Owner

@raynorpat commented on GitHub (Oct 20, 2026):

Fixed by d95feb4e2, merged into ffs-perf in 4fd6d07b6 (verification in the issue body).

@raynorpat commented on GitHub (Oct 20, 2026): Fixed by d95feb4e2, merged into ffs-perf in 4fd6d07b6 (verification in the issue body).