Skip to content

Commit d9ee3ff

Browse files
Yongjian Suntytso
authored andcommitted
ext4: improve integrity checking in __mb_check_buddy by enhancing order-0 validation
When the MB_CHECK_ASSERT macro is enabled, we found that the current validation logic in __mb_check_buddy has a gap in detecting certain invalid buddy states, particularly related to order-0 (bitmap) bits. The original logic consists of three steps: 1. Validates higher-order buddies: if a higher-order bit is set, at most one of the two corresponding lower-order bits may be free; if a higher-order bit is clear, both lower-order bits must be allocated (and their bitmap bits must be 0). 2. For any set bit in order-0, ensures all corresponding higher-order bits are not free. 3. Verifies that all preallocated blocks (pa) in the group have pa_pstart within bounds and their bitmap bits marked as allocated. However, this approach fails to properly validate cases where order-0 bits are incorrectly cleared (0), allowing some invalid configurations to pass: corrupt integral order 3 1 1 order 2 1 1 1 1 order 1 1 1 1 1 1 1 1 1 order 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 Here we get two adjacent free blocks at order-0 with inconsistent higher-order state, and the right one shows the correct scenario. The root cause is insufficient validation of order-0 zero bits. To fix this and improve completeness without significant performance cost, we refine the logic: 1. Maintain the top-down higher-order validation, but we no longer check the cases where the higher-order bit is 0, as this case will be covered in step 2. 2. Enhance order-0 checking by examining pairs of bits: - If either bit in a pair is set (1), all corresponding higher-order bits must not be free. - If both bits are clear (0), then exactly one of the corresponding higher-order bits must be free 3. Keep the preallocation (pa) validation unchanged. This change closes the validation gap, ensuring illegal buddy states involving order-0 are correctly detected, while removing redundant checks and maintaining efficiency. Fixes: c9de560 ("ext4: Add multi block allocator for ext4") Suggested-by: Jan Kara <jack@suse.cz> Signed-off-by: Yongjian Sun <sunyongjian1@huawei.com> Reviewed-by: Baokun Li <libaokun1@huawei.com> Reviewed-by: Jan Kara <jack@suse.cz> Message-ID: <20251106060614.631382-3-sunyongjian@huaweicloud.com> Signed-off-by: Theodore Ts'o <tytso@mit.edu>
1 parent 3f7a79d commit d9ee3ff

1 file changed

Lines changed: 32 additions & 17 deletions

File tree

fs/ext4/mballoc.c

Lines changed: 32 additions & 17 deletions
Original file line numberDiff line numberDiff line change
@@ -682,6 +682,24 @@ do { \
682682
} \
683683
} while (0)
684684

685+
/*
686+
* Perform buddy integrity check with the following steps:
687+
*
688+
* 1. Top-down validation (from highest order down to order 1, excluding order-0 bitmap):
689+
* For each pair of adjacent orders, if a higher-order bit is set (indicating a free block),
690+
* at most one of the two corresponding lower-order bits may be clear (free).
691+
*
692+
* 2. Order-0 (bitmap) validation, performed on bit pairs:
693+
* - If either bit in a pair is set (1, allocated), then all corresponding higher-order bits
694+
* must not be free (0).
695+
* - If both bits in a pair are clear (0, free), then exactly one of the corresponding
696+
* higher-order bits must be free (0).
697+
*
698+
* 3. Preallocation (pa) list validation:
699+
* For each preallocated block (pa) in the group:
700+
* - Verify that pa_pstart falls within the bounds of this block group.
701+
* - Ensure the corresponding bit(s) in the order-0 bitmap are marked as allocated (1).
702+
*/
685703
static void __mb_check_buddy(struct ext4_buddy *e4b, char *file,
686704
const char *function, int line)
687705
{
@@ -723,15 +741,6 @@ static void __mb_check_buddy(struct ext4_buddy *e4b, char *file,
723741
continue;
724742
}
725743

726-
/* both bits in buddy2 must be 1 */
727-
MB_CHECK_ASSERT(mb_test_bit(i << 1, buddy2));
728-
MB_CHECK_ASSERT(mb_test_bit((i << 1) + 1, buddy2));
729-
730-
for (j = 0; j < (1 << order); j++) {
731-
k = (i * (1 << order)) + j;
732-
MB_CHECK_ASSERT(
733-
!mb_test_bit(k, e4b->bd_bitmap));
734-
}
735744
count++;
736745
}
737746
MB_CHECK_ASSERT(e4b->bd_info->bb_counters[order] == count);
@@ -747,15 +756,21 @@ static void __mb_check_buddy(struct ext4_buddy *e4b, char *file,
747756
fragments++;
748757
fstart = i;
749758
}
750-
continue;
759+
} else {
760+
fstart = -1;
751761
}
752-
fstart = -1;
753-
/* check used bits only */
754-
for (j = 0; j < e4b->bd_blkbits + 1; j++) {
755-
buddy2 = mb_find_buddy(e4b, j, &max2);
756-
k = i >> j;
757-
MB_CHECK_ASSERT(k < max2);
758-
MB_CHECK_ASSERT(mb_test_bit(k, buddy2));
762+
if (!(i & 1)) {
763+
int in_use, zero_bit_count = 0;
764+
765+
in_use = mb_test_bit(i, buddy) || mb_test_bit(i + 1, buddy);
766+
for (j = 1; j < e4b->bd_blkbits + 2; j++) {
767+
buddy2 = mb_find_buddy(e4b, j, &max2);
768+
k = i >> j;
769+
MB_CHECK_ASSERT(k < max2);
770+
if (!mb_test_bit(k, buddy2))
771+
zero_bit_count++;
772+
}
773+
MB_CHECK_ASSERT(zero_bit_count == !in_use);
759774
}
760775
}
761776
MB_CHECK_ASSERT(!EXT4_MB_GRP_NEED_INIT(e4b->bd_info));

0 commit comments

Comments
 (0)