Re: [PATCH] ext4: skip extra isize expansion while unmounting

[Hemanth Selam <hemanth.selam@gmail.com>]

On Mon, Aug 24, 2026 at 10:01:41AM +0000, sashiko-bot@kernel.org wrote:
> This isn't a bug introduced by this patch, but does checking s_root here
> without synchronization leave a race open during unmount?

The s_root test is advisory, like the SB_ACTIVE test next to it, and the
patch does not change that.  The race you describe is the
check-then-dereference inside ext4_xattr_inode_create() itself, between
the s_root == NULL test and the inode->i_sb->s_root->d_inode dereference
eleven lines below it.  That predates this patch and is untouched by it.

What the patch changes is how often that code is reached.  Without it,
anything that dirties an inode after shrink_dcache_for_umount() has
cleared s_root and before SB_ACTIVE is cleared walks into
ext4_xattr_block_set() and hits the warning.  That is the path syzbot
reproduces, and there the caller is the unmounting task itself - iput() of
a lazytime inode - so no second thread is involved.  With the patch those
callers get -EBUSY first, so the window your scenario needs gets smaller
rather than larger.

Of the two workers: ext4_ea_inode_work() only iput()s EA inodes, which
carry no in-body xattrs, so it never reaches
ext4_xattr_inode_lookup_create().  ext4_end_io_rsv_work() does reach
ext4_mark_inode_dirty() via ext4_convert_unwritten_extents() and is only
flushed in ext4_put_super(), so it can run in that window - and with this
patch it gets -EBUSY there too.

> Or if s_root is cleared right before the warning check inside
> ext4_xattr_inode_create(), wouldn't we still hit the original warning?

Yes, and it returns -EINVAL exactly as it does today.  The patch removes
the deterministic path syzbot found, not that check.  Flushing
rsv_conversion_wq and s_ea_inode_work before shrink_dcache_for_umount()
would close the rest; I can send that separately if it is wanted.

Thanks,
Hemanth