Re: [PATCH] jbd2: assign different lock_class_key for different filesystem

Jan Kara
2025-10-22T10:49:16Z

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@suse.com>
SUSE Labs, CR