__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 --- 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