Re: WARNING in jbd2_journal_update_sb_log_tail

From: Jan Kara
Date: Tue Jan 14 2025 - 07:29:37 EST


On Tue 14-01-25 14:25:21, Heming Zhao wrote:
> Hi Jan,
>
> On 1/6/25 23:14, Jan Kara wrote:
> > On Tue 31-12-24 13:53:23, Liebes Wang wrote:
> > > Dear Linux maintainers and reviewers:
> > >
> > > We are reporting a Linux kernel bug titled **WARNING in
> > > jbd2_journal_update_sb_log_tail**, discovered using a modified version of
> > > Syzkaller.
> >
> > Very likely this is actually some issue with ocfs2 since the only thing the
> > reproducer seems to be doing is that it is mounting ocfs2 image. Joseph,
> > can you have a look please?
> >
>
> The root cause appears to be that the jbd2 bypass recovery logic
> is incorrect.
>
> From the console log [1]:
> [ 70.568684][ T5316] JBD2: Ignoring recovery information on journal
>
> The above output indicates that ocfs2 is calling jbd2_journal_wipe()
> to clean up jbd2. (IIUC), Therefore, the subsequent jbd2 initialization
> flow should not perform any recovery tasks.
>
> However, in this crash issue, after calling jbd2_journal_wipe(),
> jbd2_journal_load() still attempts to perform a recovery, which triggers
> a WARN_ON().
>
> On the other hand, the jbd2 code logic is correct, ocfs2 should call
> ocfs2_journal_wipe() with the parameter 'write=1' to address this issue.
>
> code flow:
> ocfs2_mount_volume
> ocfs2_check_volume
> + ocfs2_journal_init => jbd2_journal_init_inode
> + ocfs2_journal_wipe => jbd2_journal_wipe (input write is 0)
> + ocfs2_journal_load => jbd2_journal_load => do recovery job => WARN_ON()
>
> [1]: 2024/01/12 06:56 log
> https://syzkaller.appspot.com/text?tag=CrashLog&x=106f2bc4580000

Ah, ok. So the problem essentially is that OCFS2 journal inode has
OCFS2_JOURNAL_DIRTY_FL cleared (hence ocfs2_journal_wipe() is called) but
the journal actually has journal->j_head != journal->j_tail and hence
recovery will replay transactions. I guess calling jbd2_journal_wipe()
with write==1 makes sense (if writing to the block device is allowed).

Honza
--
Jan Kara <jack@xxxxxxxx>
SUSE Labs, CR