Re: [PATCH v7 0/4] ext4: fix xattr iput deadlock with s_writepages_rwsem
From: Zhou, Yun
Date: Wed Jun 17 2026 - 20:28:57 EST
On 6/18/26 02:13, Jan Kara wrote:
CAUTION: This email comes from a non Wind River email account!
Do not click links or open attachments unless you recognize the sender and know the content is safe.
On Tue 16-06-26 23:15:54, Yun Zhou wrote:
This series fixes a circular lock dependency reported by syzbot:Please don't send the series so quickly. I'd say twice per week is about
s_writepages_rwsem --> jbd2_handle --> xattr_sem --> s_writepages_rwsem
The deadlock occurs when iput() on an EA inode triggers write_inode_now()
while xattr_sem and a jbd2 handle are held. The triggering path is
during mount-time orphan cleanup (!SB_ACTIVE) where iput_final() calls
write_inode_now() synchronously.
Patch 1 blocks the deadlock by skipping extra isize expansion when
!SB_ACTIVE -- this prevents the xattr manipulation path from being
entered during mount.
Patch 2 is a belt-and-suspenders semantic improvement: an inode under
eviction never needs extra isize expansion.
Patches 3-4 are a structural improvement using a per-sb workqueue:
Patch 3 introduces ext4_put_ea_inode(), which does direct iput() when
SB_ACTIVE (zero overhead) and defers to a workqueue when !SB_ACTIVE.
It also converts the first call site (ext4_xattr_block_set release
path) which previously called iput under xattr_sem + jbd2 handle.
Patch 4 converts the remaining EA inode iput() calls that execute
under locks. Sites where direct iput() is provably safe (i_nlink=0
after dec_ref, or lookup-only paths) are left unchanged with comments.
Link: https://syzkaller.appspot.com/bug?extid=5d19358d7eb30ffb0cc5
maximum sensible cadence. It takes time (easily several days) for people to
get to look at your patches and sending your patches sometimes even several
times per day just creates a mess in the mailbox.
I admit I've been pushing patches too frequently, but I'll definitely tone
it down going forward. The reason is that I get feedback from the 'AI Review'
almost immediately after submitting. It flags a lot of edge cases—some I
introduced, others that were pre-existing, or even deadlock paths I missed
despite claiming they were fixed. Most of these are genuine issues. Even if
some are extremely strict, I just want to resolve them as quickly as possible.
I mistakenly thought that once the AI Reviewer raised concerns, human reviewers
wouldn't check it again. So I kept pushing new patches to fix those potential
issues, only for the bot to immediately flag new ones... It would be great if there
were a way to send patches directly to the AI bot for a separate review.
Also in some previous version, I gave my Reviewed-by tag for patch 1 andGot it, I will add it in the next version.
some comment and Reviewed-by tag for patch 2. So please reflect that in the
next posting.
Thanks,
Yun