Well, this took way too long to find, in retrospect.
In short, for a completely full filesystem with more than 2^32
blocks, the rbtree bitmap backend can assemble an extent of used
blocks which is longer than 2^32. If it does, it will overflow
->count, and corrupt the rbtree for the bitmaps.
Discovered by completely filling a 32T filesystem using fallocate, and
then observing debugfs, dumpe2fs, and e2fsck all behaving badly.
(Note that filling with only 31 x 1T files did not show the problem,
because freespace was fragmented enough that there was no sufficiently
long range of used blocks.)
Signed-off-by: Eric Sandeen <sandeen@xxxxxxxxxx>
---
An alternative solution might be to limit the rb_extent to
32-bit counts, and not merging beyond that. For fragmented
freespace, as normal, perhaps that would be a better memory
savings? But this fixes the immediate problem and seems worth
merging to avoid bad situations such as e2fsck corrupting a
perfectly good 32T filesystem...
diff --git a/lib/ext2fs/blkmap64_rb.c b/lib/ext2fs/blkmap64_rb.c
index 7ab72f4..a83f8ac 100644
--- a/lib/ext2fs/blkmap64_rb.c
+++ b/lib/ext2fs/blkmap64_rb.c
@@ -33,7 +33,7 @@
struct bmap_rb_extent {
struct rb_node node;
__u64 start;
- __u32 count;
+ __u64 count;
};
struct ext2fs_rb_private {
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
