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

[shuo chen <1289151713@qq.com>]

> [Severity: High]
> Does this hardcode the extent length to 1 block, potentially leaking blocks if 
> ext4_mb_new_blocks() allocates a larger contiguous extent?
> 
> In ext4_convert_inline_data_nolock(), the actual allocation size is captured
> as allocated_block = EXT4_C2B(sbi, ar.len). If the allocation request returns
> multiple blocks (for example, on a bigalloc filesystem), only the first block
> is added to the extent tree here. The remaining blocks appear to be neither
> mapped nor freed, which would leave them orphaned in the block bitmap.
This is a false positive. The remaining blocks are stored in i_prealloc_node, 
so they will not be leaked.
> 
> [Severity: High]
> Can this error path result in a permanent data block leak?
> 
> If ext4_ext_insert_extent() fails with an error like -ENOMEM or -EIO, the
> code jumps directly to the no_free label. This deliberately bypasses the
> ext4_free_blocks() call just above it. Because the calling function relies
> on ext4_set_inline_data_block() to free the newly allocated block on error,
> bypassing the free operation here appears to leave the blocks permanently
> marked as used in the filesystem.
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"