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

Message-ID: <doq4csrkuhpha7v5lunesdrscmqmjvt3flids3iai2gvpbhp3j@mxldi4yvvymw>
Date: Tue, 21 Oct 2025 15:39:47 +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 Tue 21-10-25 20:16:53, Tetsuo Handa wrote:
> On 2025/10/20 21:55, Jan Kara wrote:
> > On Mon 20-10-25 20:28:54, Tetsuo Handa wrote:
> >> On 2025/10/20 18:31, Jan Kara wrote:
> >>> On Sun 19-10-25 19:52:43, Tetsuo Handa wrote:
> >>>> syzbot is reporting possibility of deadlock due to sharing lock_class_key
> >>>> for jbd2_handle across ext4 and ocfs2. But one disk partition can't have
> >>>> two filesystems at the same time, and how locks in journal_t interacts
> >>>> with other filesystem specific locks can vary depending on filesystems.
> >>>> Therefore, lockdep should treat locks in journal_t different locks if
> >>>> the filesystem which allocated the journal_t differs.
> >>>
> >>> Thanks for debugging this. I agree with the idea of your solution but the
> >>> implementation is just ugly. Just let the filesystem pass the lockdep key
> >>> into jbd2_journal_init_dev() / jbd2_journal_init_inode() and make ext4 and
> >>> ocfs2 functions initializing the journal each have its own lock_class_key
> >>> declared and pass it to jbd2 functions. That way changes are much simpler
> >>> and also jbd2 doesn't have to be aware about which filesystems are using
> >>> it.
> >>
> >> Well, do you mean something like below diff? If we can assume that only ext4
> >> and ocfs2 are using jbd2, the diff becomes smaller...
> > 
> > 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...

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