__ext4_mark_inode_dirty may be called from the eviction/free path (via
ext4_truncate → ext4_ext_truncate → mark_inode_dirty), which may call
ext4_try_to_expand_extra_isize() that could create a new EA inode,
wasting work that will be immediately discarded.

Skip the expansion when the inode is transitioning to freed.

Signed-off-by: Helen Koike <koike@igalia.com>
---

Hello,

I saw this while investigating the syzbot issue (see the stack trace of
unlink "-> #0"):
   https://syzkaller.appspot.com/bug?extid=d91a6e2efb07bd3354e9

While the reported issue is fixed by:
  7f473f971382 ("ext4: lockdep: handle i_data_sem subclassing for special inodes")
I believe the call to ext4_try_to_expand_extra_isize() in the eviction
path doesn't make sense in the first place.

I understand this is not a major optimization, so not a high priority,
but sending it anyway in case anyone finds it useful.
---
 fs/ext4/inode.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index ce99807c5f5b..cea3405cd841 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -6603,7 +6603,8 @@ int __ext4_mark_inode_dirty(handle_t *handle, struct inode *inode,
 	if (err)
 		goto out;
 
-	if (EXT4_I(inode)->i_extra_isize < sbi->s_want_extra_isize)
+	if (EXT4_I(inode)->i_extra_isize < sbi->s_want_extra_isize &&
+	    !(inode_state_read_once(inode) & (I_FREEING | I_WILL_FREE)))
 		ext4_try_to_expand_extra_isize(inode, sbi->s_want_extra_isize,
 					       iloc, handle);
 
-- 
2.54.0

On Wed, Jul 15, 2026 at 02:52:25PM -0500, Helen Koike wrote:
> __ext4_mark_inode_dirty may be called from the eviction/free path (via
> ext4_truncate ??? ext4_ext_truncate ??? mark_inode_dirty), which may call
> ext4_try_to_expand_extra_isize() that could create a new EA inode,
> wasting work that will be immediately discarded.
> 
> Skip the expansion when the inode is transitioning to freed.
> 
> Signed-off-by: Helen Koike <koike@igalia.com>

This issue has been addressed via the patch[1] "ext4: set
EXT4_STATE_NO_EXPAND in ext4_evict_inode".

[1] https://patch.msgid.link/20260623061903.2148767-2-yun.zhou@windriver.com

Thanks,

						- Ted

On Jul 15, 2026, at 11:52, Helen Koike <koike@igalia.com> wrote:
> 
> __ext4_mark_inode_dirty may be called from the eviction/free path (via
> ext4_truncate → ext4_ext_truncate → mark_inode_dirty), which may call
> ext4_try_to_expand_extra_isize() that could create a new EA inode,
> wasting work that will be immediately discarded.
> 
> Skip the expansion when the inode is transitioning to freed.
> 
> Signed-off-by: Helen Koike <koike@igalia.com>

Reviewed-by: Andreas Dilger <adilger@dilger.ca <mailto:adilger@dilger.ca>>

> ---
> 
> Hello,
> 
> I saw this while investigating the syzbot issue (see the stack trace of
> unlink "-> #0"):
>   https://syzkaller.appspot.com/bug?extid=d91a6e2efb07bd3354e9
> 
> While the reported issue is fixed by:
>  7f473f971382 ("ext4: lockdep: handle i_data_sem subclassing for special inodes")
> I believe the call to ext4_try_to_expand_extra_isize() in the eviction
> path doesn't make sense in the first place.
> 
> I understand this is not a major optimization, so not a high priority,
> but sending it anyway in case anyone finds it useful.
> ---
> fs/ext4/inode.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
> index ce99807c5f5b..cea3405cd841 100644
> --- a/fs/ext4/inode.c
> +++ b/fs/ext4/inode.c
> @@ -6603,7 +6603,8 @@ int __ext4_mark_inode_dirty(handle_t *handle, struct inode *inode,
> if (err)
> goto out;
> 
> -	if (EXT4_I(inode)->i_extra_isize < sbi->s_want_extra_isize)
> +	if (EXT4_I(inode)->i_extra_isize < sbi->s_want_extra_isize &&
> +	     !(inode_state_read_once(inode) & (I_FREEING | I_WILL_FREE)))
>  		ext4_try_to_expand_extra_isize(inode, sbi->s_want_extra_isize,
>  					       iloc, handle);
> 
> -- 
> 2.54.0
> 


Cheers, Andreas