Re: [syzbot] [ext4?] possible deadlock in ext4_destroy_inline_data (2)

Andreas Dilger
2025-12-01T23:17:15Z

On Dec 1, 2025, at 9:16 AM, Theodore Tso <tytso@mit.edu> wrote:
>
> That being said, we probably should just not try to expand the inode's
> extra size while evicting the inode. In practice we don't actually do
> this since we haven't expanded the inode's extra size space in over a
> decade, and so this only happens in a debugging mount option that
> syzbot helpfully uses, and not in real life.

I think we would regret removing this if/when we *do* expand the inode
size. We used this functionality to upgrade filesystems online when
i_projid was first added and users suddenly wanted to use project quotas.
If we need some new inode field in the future it will be good to have it.

> Also, there's no real point in doing this on the evict path,
> especially if the inode is about to be released as part of the
> eviction.

This could check in ext4_orphan_cleanup()->ext4_evict_inode() path
that this is orphan cleanup with EXT4_ORPHAN_FS and skip the expansion?
As you write, it doesn't make sense to do that when the file is being
deleted anyway. Something like the following, which adds unlikely() to
that branch since it may happen only once or never in the lifetime of
any inode:

Cheers, Andreas
---
diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index e99306a8f47c..ae48748decc5 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -6481,7 +6490,8 @@ int __ext4_mark_inode_dirty(handle_t *handle,
if (err)
goto out;
- if (EXT4_I(inode)->i_extra_isize < sbi->s_want_extra_isize)
+ if (unlikely(EXT4_I(inode)->i_extra_isize < sbi->s_want_extra_isize &&
+ !(sbi->s_mount_state & EXT4_ORPHAN_FS)))
ext4_try_to_expand_extra_isize(inode, sbi->s_want_extra_isize,
iloc, handle);