From: Baokun Li <libaokun@linux.alibaba.com>
To: sashiko@lists.linux.dev
Cc: tytso@mit.edu, libaokun@linux.alibaba.com
Subject: Re: [PATCH RFC 06/17] ext4: add ext4_block_bitmap_csum_set_range() for incremental checksum update
Date: Mon, 11 May 2026 16:31:04 +0800 [thread overview]
Message-ID: <bb3ffe68-8b0b-4fca-be74-f3a398746015@linux.alibaba.com> (raw)
In-Reply-To: <20260508214640.B3A74C2BCB0@smtp.kernel.org>
在 2026/5/9 05:46, sashiko-bot@kernel.org 写道:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [High] ext4_block_bitmap_csum_set_range() passes an incorrect `total_bits` value to `crc32c_flip_range()` when `EXT4_CLUSTERS_PER_GROUP(sb)` is not a multiple of 8, leading to corrupted checksums.
> --
>
> commit 49b9ace366232b1d340c2393c53c09a694007211
> Author: Baokun Li <libaokun@linux.alibaba.com>
>
> ext4: add ext4_block_bitmap_csum_set_range() for incremental checksum update
>
> This commit adds a helper function to incrementally update the block bitmap
> checksum using crc32c_flip_range(). This efficiently computes the CRC delta
> for a range of flipped bits without re-scanning the entire bitmap buffer.
>
>> diff --git a/fs/ext4/bitmap.c b/fs/ext4/bitmap.c
>> index 46affc9e80ca3..00b0a3c748596 100644
>> --- a/fs/ext4/bitmap.c
>> +++ b/fs/ext4/bitmap.c
> [ ... ]
>> +void ext4_block_bitmap_csum_set_range(struct super_block *sb,
>> + struct ext4_group_desc *gdp,
>> + ext4_grpblk_t offset, ext4_grpblk_t len)
>> +{
>> + __u32 new_csum, old_csum;
>> +
>> + if (!ext4_has_feature_metadata_csum(sb))
>> + return;
>> +
>> + old_csum = ext4_block_bitmap_csum_get(sb, gdp);
>> + new_csum = crc32c_flip_range(old_csum, EXT4_CLUSTERS_PER_GROUP(sb),
>> + offset, len);
> Does passing EXT4_CLUSTERS_PER_GROUP(sb) here cause a checksum mismatch if
> the clusters per group is not a multiple of 8?
>
> In ext4_block_bitmap_csum_set(), the full checksum is calculated over exactly
> EXT4_CLUSTERS_PER_GROUP(sb) / 8 bytes, ignoring fractional trailing bits:
>
> fs/ext4/bitmap.c:ext4_block_bitmap_csum_set() {
> int sz = EXT4_CLUSTERS_PER_GROUP(sb) / 8;
> ...
> csum = ext4_chksum(sbi->s_csum_seed, (__u8 *)bh->b_data, sz);
> }
>
> If crc32c_flip_range() uses the unaligned bit count as total_bits, the
> trailing_bits shift calculation will use the wrong baseline length. This
> could result in an incorrect checksum delta being applied for bit flips
> within the byte-aligned region.
>
> Would this also erroneously apply a CRC delta if an allocation or free occurs
> in the fractional trailing bits that the full recalculation ignores?
>
>> +
>> + ext4_block_bitmap_csum_store(sb, gdp, new_csum);
>> +}
Yes, I missed the case of errors=continue. In the next version, I will
revert to full calculation when EXT4_ERROR_FS is set.
Thanks,
Baokun
prev parent reply other threads:[~2026-05-11 8:31 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20260508121539.4174601-7-libaokun@linux.alibaba.com>
[not found] ` <20260508214640.B3A74C2BCB0@smtp.kernel.org>
2026-05-11 8:09 ` [PATCH RFC 06/17] ext4: add ext4_block_bitmap_csum_set_range() for incremental checksum update Baokun Li
2026-05-11 8:31 ` Baokun Li [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bb3ffe68-8b0b-4fca-be74-f3a398746015@linux.alibaba.com \
--to=libaokun@linux.alibaba.com \
--cc=sashiko@lists.linux.dev \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox