linux-kernel - Re: [PATCH] ext4: fast commit: avoid fs_reclaim inversion in perform

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <19b933b0448.619d63104490112.7140925865813405260@linux.beauty>
Date: Tue, 06 Jan 2026 20:14:37 +0800
From: Li Chen <me@...ux.beauty>
To: "Jan Kara" <jack@...e.cz>
Cc: "Theodore Ts'o" <tytso@....edu>,
	"Andreas Dilger" <adilger.kernel@...ger.ca>,
	"Harshad Shirwadkar" <harshadshirwadkar@...il.com>,
	"linux-ext4" <linux-ext4@...r.kernel.org>,
	"linux-kernel" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] ext4: fast commit: avoid fs_reclaim inversion in
 perform_commit

Hi Jan,

 ---- On Tue, 06 Jan 2026 00:17:31 +0800  Jan Kara <jack@...e.cz> wrote --- 
 > On Tue 23-12-25 21:13:42, Li Chen wrote:
 > > lockdep reports a possible deadlock due to lock order inversion:
 > > 
 > >      CPU0                    CPU1
 > >      ----                    ----
 > > lock(fs_reclaim);
 > >                              lock(&sbi->s_fc_lock);
 > >                              lock(fs_reclaim);
 > > lock(&sbi->s_fc_lock);
 > > 
 > > ext4_fc_perform_commit() holds s_fc_lock while writing the fast commit
 > > log. Allocations here can enter reclaim and take fs_reclaim, inverting
 > > with ext4_fc_del() which runs under fs_reclaim during inode eviction.
 > > Wrap Step 6 in memalloc_nofs_save()/restore() so reclaim is skipped
 > > while s_fc_lock is held.
 > > 
 > > Fixes: 6593714d67ba ("ext4: hold s_fc_lock while during fast commit")
 > > Signed-off-by: Li Chen <me@...ux.beauty>
 > 
 > Thanks for the analysis and the patch! Your solution is in principle
 > correct but it's a bit fragile because there can be other instances (or we
 > can grow them in the future) where sbi->s_fc_lock is held when doing
 > allocation. The situation is that sbi->s_fc_lock can be acquired from inode
 > eviction path (ext4_clear_inode()) and thus this lock is inherently reclaim
 > unsafe. What we do in such cases is that we create helper functions for
 > acquiring / releasing the lock while also setting proper context and using
 > these helpers - like in commit 00d873c17e29 ("ext4: avoid deadlock in fs
 > reclaim with page writeback"). Can you perhaps modify your patch to follow
 > that behavior as well?

Thanks a lot for your suggestion, I have added helpers here: https://lore.kernel.org/linux-ext4/20260106120621.440126-1-me@linux.beauty/T/#u
Please take a look, thanks.
(But I didn't add v2 reroll count there, because I mistakenly remembered that this was an RFC, sorry for this)

Regards,
Li