[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <1d3f056c-f32d-4f47-a325-42ac88b0c981@huaweicloud.com>
Date: Tue, 30 Sep 2025 17:15:43 +0800
From: Zhang Yi <yi.zhang@...weicloud.com>
To: Deepanshu Kartikey <kartikey406@...il.com>
Cc: tytso@....edu, adilger.kernel@...ger.ca, linux-ext4@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] ext4: detect invalid INLINE_DATA + EXTENTS flag
combination
On 9/30/2025 5:02 PM, Deepanshu Kartikey wrote:
> Zhang Yi,
>
> Thank you for the review. Regarding the placement after ext4_set_inode_flags() -
> this would be too early. My debug shows that i_inline_off changes during inode
> initialization:
>
> After ext4_set_inode_flags(): flag=1, i_inline_off=0, has_inline=0
> Before my patch validation check: flag=1, i_inline_off=164, has_inline=1
>
> At the earlier point, ext4_has_inline_data() returns false, so we wouldn't catch
> the corruption. The check needs to be after all inode fields are initialized.
>
The return value of ext4_has_inline_data() changed since ext4_iget_extra_inode()
initialize the i_inline_off parameter from the ondisk inline xattr. However, in
your v2 patch, you checked the EXT4_INODE_INLINE_DATA flags directly instead of
the return value of ext4_has_inline_data(). The flags will not change, so it's
safe to move this check eralier, and it is more reasonable to directly check the
flags after getting flags from the disk and before checking inline xattr.
Thanks,
Yi.
> I'll fix the alignment and use function/line variables as you suggested, but keep
> the check after "ret = 0;" where all inode fields are populated.
>
> I'll send v3 with these fixes shortly.
>
> Best regards,
> Deepanshu
>
Powered by blists - more mailing lists