freebsd boot error: panic: Assertion in_epoch(net_epoch_preempt) failed at /syzkaller/managers/i386/kernel/sys/net/if.c:LINE

1 view
Skip to first unread message

syzbot

unread,
Oct 8, 2019, 6:54:07 AM10/8/19
to syzkaller-f...@googlegroups.com
Hello,

syzbot found the following crash on:

HEAD commit: 918670a5 Define macro VM_MAP_ENTRY_FOREACH for enumerating..
git tree: freebsd
console output: https://syzkaller.appspot.com/x/log.txt?x=1104ccb3600000
dashboard link: https://syzkaller.appspot.com/bug?extid=631f400c0275b549de37
userspace arch: i386

Unfortunately, I don't have any reproducer for this crash yet.

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+631f40...@syzkaller.appspotmail.com

panic: Assertion in_epoch(net_epoch_preempt) failed at
/syzkaller/managers/i386/kernel/sys/net/if.c:3694
cpuid = 1
time = 1570531453
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x47/frame
0xfffffe001a110850
vpanic() at vpanic+0x1e0/frame 0xfffffe001a1108b0
panic() at panic+0x43/frame 0xfffffe001a110910
if_delmulti_ifma_flags() at if_delmulti_ifma_flags+0x1af/frame
0xfffffe001a110950
inm_release_task() at inm_release_task+0x345/frame 0xfffffe001a1109c0
gtaskqueue_run_locked() at gtaskqueue_run_locked+0x13e/frame
0xfffffe001a110a20
gtaskqueue_thread_loop() at gtaskqueue_thread_loop+0xdd/frame
0xfffffe001a110a60
fork_exit() at fork_exit+0xb0/frame 0xfffffe001a110ab0
fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe001a110ab0
--- trap 0, rip = 0, rsp = 0, rbp = 0 ---
KDB: enter: panic
[ thread pid 0 tid 100005 ]
Stopped at kdb_enter+0x6a: movq $0,kdb_why
db>


---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzk...@googlegroups.com.

syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

Mark Johnston

unread,
Oct 8, 2019, 5:02:08 PM10/8/19
to syzbot, syzkaller-f...@googlegroups.com
#syz fix: In DIAGNOSTIC block of if_delmulti_ifma_flags() enter the network epoch. This quickly plugs the regression from r353292. The locking of multicast definitely needs a broader review today...

Mark Johnston

unread,
Oct 16, 2019, 12:15:14 PM10/16/19
to syzbot, syzkaller-f...@googlegroups.com
On Tue, Oct 08, 2019 at 03:54:06AM -0700, syzbot wrote:
#syz fix: Quickly plug another regression from r353292. Again, multicast locking needs lots of work...
Reply all
Reply to author
Forward
0 new messages