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: <a6fcc693-42f0-4d70-a1af-fc1bfb328eb7@I-love.SAKURA.ne.jp>
Date: Wed, 22 Oct 2025 19:04:33 +0900
From: Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
To: Jan Kara <jack@...e.cz>
Cc: "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 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?