Re: [PATCH v2] ext4: propagate errors from fast commit i_blocks replay

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Incomplete error propagation in `ext4_ext_replay_set_iblocks` when encountering an empty extent leaf.
--

commit d0296b8bc160aac911c99a12a53e4f06189bb5cd
Author: lty <781735889@qq.com>

ext4: propagate errors from fast commit i_blocks replay

This commit modifies ext4_ext_replay_set_iblocks() to stop calculating
blocks and propagate errors when mapping fails. It ensures failures from
extent lookups abort the fast commit inode replay.

> diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c
> --- a/fs/ext4/extents.c
> +++ b/fs/ext4/extents.c

[ ... ]

> @@ -6291,15 +6291,19 @@ int ext4_ext_replay_set_iblocks(struct inode *inode)
>  	numblks += path->p_depth;
>  	while (cur < end) {
>  		path = ext4_find_extent(inode, cur, path, 0);
> -		if (IS_ERR(path))
> -			break;
> +		if (IS_ERR(path)) {
> +			ret = PTR_ERR(path);
> +			goto cleanup;
> +		}
>  		ex = path[path->p_depth].p_ext;
>  		if (!ex)
>  			goto cleanup;

[Severity: High]
Since ret is 0 on a successful extent lookup, does this branch silently return
success when it encounters an empty extent leaf?

If an empty leaf (!ex) represents a corrupted extent tree, should this set an
error code like -EFSCORRUPTED before jumping to cleanup, so the fast commit
replay can properly abort?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/tencent_BCDA824359279D18963B838B15B01BC1CD06@qq.com?part=1