Re: [PATCH] ext4: fix extent status cache clearing when truncating inline data

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] ext4: integer truncation of i_size in ext4_inline_data_truncate()
--

commit dadd6832c867f600a26266f1d17a57f7cfd12f24
Author: Zhang Yi <yi.zhang@huawei.com>
Subject: ext4: fix extent status cache clearing when truncating inline data

This commit restricts the extent status cache clear range during inline data
truncation. Instead of dropping the whole extent status tree, it clears only
the blocks that are actually truncated away to prevent inconsistencies with
dirty, mapped, and delayed buffers.

Link: https://lore.kernel.org/linux-ext4/20261009103033.2920530-9-yi.zhang@huaweicloud.com/
Link: https://lore.kernel.org/linux-ext4/6ac92a4c.70ed5d86.2ac85.0072.GAE@google.com/

> diff --git a/fs/ext4/inline.c b/fs/ext4/inline.c
> index ceee69a66482b..b630e56815bb5 100644
> --- a/fs/ext4/inline.c
> +++ b/fs/ext4/inline.c
[ ... ]
> @@ -1905,8 +1905,12 @@ int ext4_inline_data_truncate(struct inode *inode, int *has_inline)
>  		 * the extent status cache must be cleared to avoid leaving
>  		 * behind stale delayed allocated extent entries
>  		 */
> -		if (!ext4_test_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA))
> -			ext4_es_remove_extent(inode, 0, EXT_MAX_BLOCKS);
> +		if (!ext4_test_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA)) {
> +			ext4_lblk_t lblk = EXT4_B_TO_LBLK(inode, i_size);
> +
> +			ext4_es_remove_extent(inode, lblk,
> +					      EXT_MAX_BLOCKS - lblk);
> +		}

[Severity: High]
Does this calculation inadvertently drop valid delayed allocation extents on
32-bit architectures for files larger than 4GB?

Looking at ext4_inline_data_truncate(), the local variable i_size is
declared as a size_t:

fs/ext4/inline.c:ext4_inline_data_truncate() {
        size_t i_size;
        ...
        i_size = inode->i_size;
        EXT4_I(inode)->i_disksize = i_size;
        ...
}

On 32-bit architectures, size_t is 32-bit, while inode->i_size is a 64-bit
loff_t.

If a file with inline data is extended beyond 4GB via a delayed allocation
write, inode->i_size successfully updates to >4GB. A subsequent failed write
past EOF (e.g., from ENOSPC) triggers ext4_truncate_failed_write(), which
calls ext4_inline_data_truncate().

Because i_size is a 32-bit size_t, the 64-bit inode->i_size wraps around
(e.g., 4GB + 10 truncates to 10). When this patch uses the truncated i_size
to calculate lblk, lblk incorrectly evaluates to a block near 0. This
results in dropping valid delayed allocation extents across the entire >4GB
file.

Additionally, the preexisting code assigns this truncated 32-bit i_size to
the 64-bit EXT4_I(inode)->i_disksize, corrupting the on-disk size. Should
i_size be changed to loff_t to prevent both the incorrect extent removal
introduced here, and the disk size corruption?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261014021714.2382353-1-yi.zhang@huaweicloud.com?part=1