Re: [PATCH v4] ext4: fix race in ext4_convert_inline_data() leading to BUG_ON in writepages

["Zhou, Yun" <yun.zhou@windriver.com>]

Hi Jan,

On 7/3/2026 9:47 PM, sashiko-bot@kernel.org wrote:

> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> - [High] The newly introduced EXT4_STATE_INLINE_CONVERTED flag is never initialized for files that naturally have no inline data, forcing every regular file to incur an empty journal transaction on its first memory-mapped write.
> - [High] ext4_convert_inline_data() returns success (0) before inline data is physically destroyed during delayed allocation conversion, breaking callers that require block-mapped inodes.
> --
> 
> commit 39b605d5de2f62ec33531991bcda64fc6c6fb005
> Author: Yun Zhou <yun.zhou@windriver.com>
> 
> ext4: fix race in ext4_convert_inline_data() leading to BUG_ON in writepages
> 
> This patch introduces the EXT4_STATE_INLINE_CONVERTED state bit to prevent
> concurrent convert_inline_data_nolock() calls from restoring inline data
> while dirty pages exist. It adds a fast path to ext4_convert_inline_data()
> using this new bit.
> 
> Closes: https://syzkaller.appspot.com/bug?extid=d1da16f03614058fdc48
> 
>> diff --git a/fs/ext4/inline.c b/fs/ext4/inline.c
>> index 0eff4a0c6a6c3..f599b84c41453 100644
>> --- a/fs/ext4/inline.c
>> +++ b/fs/ext4/inline.c
> 
> [ ... ]
> 
>> @@ -1960,21 +1969,27 @@ int ext4_convert_inline_data(struct inode *inode)
>>        handle_t *handle;
>>        struct ext4_iloc iloc;
>>
>> -     if (!ext4_has_inline_data(inode)) {
>> -             ext4_clear_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA);
>> +     if (!ext4_has_feature_inline_data(inode->i_sb))
>>                return 0;
> 
> [Severity: High]
> Are we missing an initialization of EXT4_STATE_INLINE_CONVERTED for normal
> files?
> 
> When an inode without inline data is read from disk via __ext4_iget(), the
> in-memory state bit remains uninitialized (0). Because this patch removes the
> !ext4_has_inline_data(inode) fast path check, a normal file's first
> memory-mapped write that triggers a page fault to ext4_page_mkwrite() will
> call ext4_convert_inline_data() and fall through to the slow path.
> 
> Does this mean every regular file will now unnecessarily start an empty
> journal transaction, take the xattr_sem write lock, and check
> ext4_has_inline_data() before returning?
> 

Sorry to bother you. The performance regression reported by the AI bot 
does exist, but it only occurs in filesystems with the inline_data 
feature enabled. Specifically, during the first ext4_page_mkwrite on an 
inode that has never had inline data, it triggers an extra 
ext4_journal_start() and an additional down_write(xattr_sem).

I'm not sure if this regression is acceptable when weighed against the 
BUG_ON triggered by two race conditions. Alternatively, this problem 
would naturally disappear once the inline_data feature is completely 
removed, but that seems to be a long way off. So I'd love to hear your 
thoughts on this.

BR,
Yun