[Ocfs2-devel] [PATCH 1/2] ocfs2: fix jbd2 assertion in defragment path
Joseph Qi
joseph.qi at linux.alibaba.com
Thu Jun 2 09:34:18 UTC 2022
Hi,
Sorry for the late response since I was busy on other things...
On 5/21/22 6:14 PM, Heming Zhao wrote:
> defragfs triggered jbd2 report ASSERT when working.
>
> code path:
>
> ocfs2_ioctl_move_extents
> ocfs2_move_extents
> __ocfs2_move_extents_range
> ocfs2_defrag_extent
> __ocfs2_move_extent
> + ocfs2_journal_access_di
> + ocfs2_split_extent //[1]
> + ocfs2_journal_dirty //crash
>
> [1]: ocfs2_split_extent called ocfs2_extend_trans, which committed
> dirty buffers then restarted the transaction. The changed transaction
> triggered jbd2 ASSERT.
>
> crash stacks:
>
> PID: 11297 TASK: ffff974a676dcd00 CPU: 67 COMMAND: "defragfs.ocfs2"
> #0 [ffffb25d8dad3900] machine_kexec at ffffffff8386fe01
> #1 [ffffb25d8dad3958] __crash_kexec at ffffffff8395959d
> #2 [ffffb25d8dad3a20] crash_kexec at ffffffff8395a45d
> #3 [ffffb25d8dad3a38] oops_end at ffffffff83836d3f
> #4 [ffffb25d8dad3a58] do_trap at ffffffff83833205
> #5 [ffffb25d8dad3aa0] do_invalid_op at ffffffff83833aa6
> #6 [ffffb25d8dad3ac0] invalid_op at ffffffff84200d18
> [exception RIP: jbd2_journal_dirty_metadata+0x2ba]
> RIP: ffffffffc09ca54a RSP: ffffb25d8dad3b70 RFLAGS: 00010207
> RAX: 0000000000000000 RBX: ffff9706eedc5248 RCX: 0000000000000000
> RDX: 0000000000000001 RSI: ffff97337029ea28 RDI: ffff9706eedc5250
> RBP: ffff9703c3520200 R8: 000000000f46b0b2 R9: 0000000000000000
> R10: 0000000000000001 R11: 00000001000000fe R12: ffff97337029ea28
> R13: 0000000000000000 R14: ffff9703de59bf60 R15: ffff9706eedc5250
> ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018
> #7 [ffffb25d8dad3ba8] ocfs2_journal_dirty at ffffffffc137fb95 [ocfs2]
> #8 [ffffb25d8dad3be8] __ocfs2_move_extent at ffffffffc139a950 [ocfs2]
> #9 [ffffb25d8dad3c80] ocfs2_defrag_extent at ffffffffc139b2d2 [ocfs2]
>
> The fix method is simple, ocfs2_split_extent includes three paths. all
> the paths already have journal access/dirty pair. We only need to
> remove journal access/dirty from __ocfs2_move_extent.
>
I am not sure what you mean by "all three paths have journal access/
dirty pair".
It seems we can't do it in your way, as journal access has different
ocfs2_trigger with different offset, e.g. dinode is different from
extent block.
Or we may reserve enough credits to resolve this issue?
Thanks,
Joseph
More information about the Ocfs2-devel
mailing list