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
