Re: [PATCH v7 24/31] ext4: defer i_disksize update while DISKSIZE_GROW_PENDING is set

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] ext4: torn reads of 64-bit i_disksize cause missed updates and data loss
--

commit 9dbea84318a994dcee69fb96db7cef1b2100ff28
Author: Zhang Yi <yi.zhang@huawei.com>

ext4: defer i_disksize update while DISKSIZE_GROW_PENDING is set

This commit defers i_disksize updates while EXT4_STATE_DISKSIZE_GROW_PENDING
is set to prevent exposing stale data on a crash. It introduces a fast-path
check in ext4_update_inode_size() to avoid taking i_data_sem when no
size update is needed.

> diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h
> index 089dbd39c5c24..b26ce3183bacb 100644
> --- a/fs/ext4/ext4.h
> +++ b/fs/ext4/ext4.h
[ ... ]
> @@ -3605,30 +3605,67 @@ do {								\
[ ... ]
>  static inline int ext4_update_inode_size(struct inode *inode, loff_t newsize)
>  {
>  	int changed = 0;
>  
> +	if (newsize <= inode->i_size && newsize <= EXT4_I(inode)->i_disksize)
> +		return 0;
> +

[Severity: High]
On 32-bit architectures, can reading the 64-bit EXT4_I(inode)->i_disksize
locklessly here result in a torn read?

Because i_disksize can be concurrently updated by ioend workers under
i_data_sem (for example, when crossing a 4GB boundary), a torn read could mix
the high 32 bits of a new value with the low 32 bits of an old value,
producing a falsely large value.

If a falsely large value is read, this new fast-path check could erroneously
evaluate to true. This would cause the function to return 0 and skip acquiring
i_data_sem to update i_disksize.

Could this leave i_disksize permanently short of newsize during operations
like ext4_zero_range or non-delalloc buffered writes, potentially resulting
in data loss if a system crash truncates the file to the smaller i_disksize?

> +	down_write(&EXT4_I(inode)->i_data_sem);
>  	if (newsize > inode->i_size) {
>  		i_size_write(inode, newsize);
>  		changed = 1;

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