Re: [PATCH v5] ext4: rewrite ext4_convert_inline_data_nolock to make it safer

[shuo chen <1289151713@qq.com>]

On Wed, Sep 02, 2026 at 10:24:16AM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> 
> [Severity: High]
> Does initializing .not_found to 0 set up a false positive match instead of
> the expected -ENODATA?
> 
> If a filesystem image is mounted where a file has EXT4_INODE_INLINE_DATA
> set but lacks the EXT4_STATE_XATTR flag, ext4_xattr_ibody_find() will exit
> early without modifying is.s.not_found.
> 
> Because it was initialized to 0 (meaning 'found'), later in this function:
> 
>     error = ext4_xattr_ibody_find(inode, &i, &is);
>     if (error)
>         goto recovery;
>     if (!is.s.not_found)
>         error = ext4_xattr_ibody_set(handle, inode, &i, &is);
> 
> The code believes a valid xattr entry exists at is.s.here (which points to
> uninitialized space). This causes ext4_xattr_ibody_set() to attempt to
> delete a bogus entry, potentially leading to out-of-bounds memory
> operations and a kernel panic.
Got it.
> 
> [ ... ]
> > +		struct ext4_extent newex;
> > +
> > +		newex.ee_block = cpu_to_le32(0);
> > +		newex.ee_len = cpu_to_le16(1);
> > +		ext4_ext_store_pblock(&newex, block);
> > +		path = ext4_ext_insert_extent(handle, inode, path, &newex, 0);
> > +		if (IS_ERR(path)) {
> > +			error = PTR_ERR(path);
> > +			if (error == -EDQUOT || error == -ENOSPC)
> > +				goto recovery;
> > +		} else {
> > +			ext4_free_ext_path(path);
> > +		}
> 
> [Severity: Critical]
> Does this restricted error check silently swallow fatal failure codes
> (like -ENOMEM or -EIO) from ext4_ext_insert_extent()?
> 
> If ext4_ext_insert_extent() fails due to memory pressure or I/O error, the
> restricted check allows the failure to fall through.
> 
> The unhandled error code is then overwritten shortly after:
> 
>     error = ext4_xattr_ibody_find(inode, &i, &is);
> 
> This completely masks the prior failure, causing the function to complete
> successfully. The inline data flag is cleared, but the newly allocated
> block is never added to the file's extent tree, permanently losing the
> file's data and leaking the block.
Got it.I will make the inode revert to inline data when the error is 
neither EDQUOT nor ENOSPC,but it will not free the blocks.
If the error is neither EDQUOT nor ENOSPC,freeing blocks here could 
lead to a more severe error.See the patch 
"avoid infinite loops caused by residual data"
> 
> -- 
> Sashiko AI review · https://sashiko.dev/#/patchset/tencent_FBF9C69AF090A1BF9003C68555A8928D1707@qq.com?part=1