linux-kernel - Re: [PATCH] jbd2: assign different lock_class

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <rajbaoxp7zvaiftmuip4mxdvrdxthhgvbjvtuq3zrwijtdab2j@ouligqrqxyth>
Date: Wed, 22 Oct 2025 12:49:05 +0200
From: Jan Kara <jack@...e.cz>
To: Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>
Cc: Jan Kara <jack@...e.cz>, Theodore Ts'o <tytso@....edu>, 
	Andreas Dilger <adilger.kernel@...ger.ca>, Jan Kara <jack@...e.com>, 
	"linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] jbd2: assign different lock_class_key for different
 filesystem

On Wed 22-10-25 19:04:33, Tetsuo Handa wrote:
> On 2025/10/21 22:39, Jan Kara wrote:
> >>> Yes, something like this. In fact, I think we could get away with just
> >>> jbd2_trans_commit_key. There's definitely no need for j_revoke_lock,
> >>> j_list_lock, j_history_lock, j_state_lock, j_abort_mutex keys as these are
> >>> internal to jbd2. j_checkpoint_mutex and j_barrier do wrap around some
> >>> filesystem code so maybe we'll need to specify keys for them but I'd start
> >>> with just jbd2_trans_commit_key and wait whether syzbot manages to trigger
> >>> another false positive report with that.
> >>
> >> I tried https://syzkaller.appspot.com/x/patch.diff?x=11b4dde2580000 .
> >> But I think https://syzkaller.appspot.com/x/patch.diff?x=1644c3cd980000
> >> pattern which all mutex_init_with_key() users follow seems more simpler
> >> and easier to apply. What do you think?
> > 
> > Yes, the second version looks nicer. Thanks! BTW, did you verify that
> > annotating j_barrier, j_checkpoint_mutex, and j_abort_mutex is really
> > needed? Because I'd be slightly surprised if it really was...
> 
> No. https://syzkaller.appspot.com/x/patch.diff?x=13a94e7c580000 was sufficient
> for this specific report. But I don't know what will happen with ocfs2 which has
> so complicated locking dependency ( https://syzkaller.appspot.com/upstream/s/ocfs2
> has currently 27 open "possible deadlock" reports).
> 
> Do you want me to try this minimal change in linux-next via my tree for a while?
> Or do you want to just apply this minimal change first?

Please just submit the minimal change and we'll merge it through ext4 tree.
If syzbot manages to trigger more reports, we can always add more
complications :). Thanks!

								Honza

-- 
Jan Kara <jack@...e.com>
SUSE Labs, CR