Issuing the following command will reboot the system: # br=$(ifconfig bridge create) # ifconfig ${br} name bridge
I am not able to reproduce this on stable or current: FreeBSD freebsd-stable 12.1-STABLE FreeBSD 12.1-STABLE r362809 GENERIC amd64 FreeBSD freebsd-current 13.0-CURRENT FreeBSD 13.0-CURRENT #0 r362198: Mon Jun 15 16:28:21 UTC 2020
I am also not able to reproduce on 12.1-RELEASE FreeBSD freebsd 12.1-RELEASE FreeBSD 12.1-RELEASE r354233 GENERIC amd64 I can't reproduce in bhyve on current, stable or release. Could you provide more details of your system? There is probably some interaction with other components.
I can't be sure without a backtrace, but I suspect Markus has pf loaded. pf panics if there's an interface and a group with the same name. See #218895. My position here is that that's a system bug, because the ability to have groups and interfaces with the same name was accidentally introduced when interface renaming was implemented. The locking around interfaces, and lack of error handling paths for renames makes this tricky to fix.
(In reply to Kristof Provost from comment #3) Would it be easy to implement prohibition of renaming interface to name of existing group if pf filtering hook is not NULL?
(In reply to Eugene Grosbein from comment #4) Offhand I don't think so. I also wouldn't expect that to fix the problem, because it can also be triggered by first naming an interface foo and then creating a group foo.
Loading pf did it. root@freebsd-current:~ # kldload pf root@freebsd-current:~ # ifconfig bridge create bridge0 root@freebsd-current:~ # ifconfig bridge0 name bridge Fatal double fault rip 0xffffffff80c0b9dc rsp 0xfffffe00aafcb000 rbp 0xfffffe00aafcb020 rax 0xfffff80003ba9140 rdx 0 rbx 0xfffff80005e9c700 rcx 0xfffff80003ccd700 rsi 0xfffff8000378c700 rdi 0 r8 0x100 r9 0xffffffff8190d980 r10 0xffffffff81d390e0 r11 0x1 r12 0 r13 0 r14 0xfffffe00aafce810 r15 0xfffff80005e9c800 rflags 0x10246 cs 0x20 ss 0x28 ds 0x3b es 0x3b fs 0x13 gs 0x1b fsbase 0x800257920 gsbase 0xffffffff82213000 kgsbase 0 cpuid = 3; apic id = 03 panic: double fault cpuid = 3 time = 1593808620 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00217b5db0 vpanic() at vpanic+0x182/frame 0xfffffe00217b5e00 panic() at panic+0x43/frame 0xfffffe00217b5e60 dblfault_handler() at dblfault_handler+0x1d1/frame 0xfffffe00217b5f20 Xdblfault() at Xdblfault+0xd7/frame 0xfffffe00217b5f20 --- trap 0x17, rip = 0xffffffff80c0b9dc, rsp = 0xfffffe00aafcb000, rbp = 0xfffffe00aafcb020 --- in_epoch_verbose() at in_epoch_verbose+0xc/frame 0xfffffe00aafcb020 pfi_kif_update() at pfi_kif_update+0x20/frame 0xfffffe00aafcb080 pfi_kif_update() at pfi_kif_update+0x27c/frame 0xfffffe00aafcb0e0 pfi_kif_update() at pfi_kif_update+0x27c/frame 0xfffffe00aafcb140 pfi_kif_update() at pfi_kif_update+0x27c/frame 0xfffffe00aafcb1a0 pfi_kif_update() at pfi_kif_update+0x27c/frame 0xfffffe00aafcb200 pfi_kif_update() at pfi_kif_update+0x27c/frame 0xfffffe00aafcb260 ... lots more ... pfi_kif_update() at pfi_kif_update+0x27c/frame 0xfffffe00aafce3e0 pfi_kif_update() at pfi_kif_update+0x27c/frame 0xfffffe00aafce440 pfi_kif_update() at pfi_kif_update+0x27c/frame 0xfffffe00aafce4a0 pfi_kif_update() at pfi_kif_update+0x27c/frame 0xfffffe00aafce500 pfi_kif_update() at pfi_kif_update+0x27c/frame 0xfffffe00aafce560 pfi_kif_update() at pfi_kif_update+0x27c/frame 0xfffffe00aafce5c0 pfi_kif_update() at pfi_kif_update+0x27c/frame 0xfffffe00aafce620 pfi_kif_update() at pfi_kif_update+0x27c/frame 0xfffffe00aafce680 pfi_kif_update() at pfi_kif_update+0x27c/frame 0xfffffe00aafce6e0 pfi_kif_update() at pfi_kif_update+0x27c/frame 0xfffffe00aafce740 pfi_kif_update() at pfi_kif_update+0x27c/frame 0xfffffe00aafce7a0 pfi_kif_update() at pfi_kif_update+0x27c/frame 0xfffffe00aafce800 pfi_attach_ifnet_event() at pfi_attach_ifnet_event+0xd6/frame 0xfffffe00aafce850 ifhwioctl() at ifhwioctl+0x10db/frame 0xfffffe00aafce8d0 ifioctl() at ifioctl+0x3ac/frame 0xfffffe00aafce9a0 kern_ioctl() at kern_ioctl+0x27b/frame 0xfffffe00aafcea00 sys_ioctl() at sys_ioctl+0x127/frame 0xfffffe00aafcead0 amd64_syscall() at amd64_syscall+0x140/frame 0xfffffe00aafcebf0 fast_syscall_common() at fast_syscall_common+0x101/frame 0xfffffe00aafcebf0 --- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x800495e8a, rsp = 0x7fffffffe278, rbp = 0x7fffffffe290 --- db>
Seems to be infinite recursion with kernel stack overflow leading to double fault. Should be easy to fix for someone familiar with the pf code. Adding glebius@ to CC: in case he likes to take a look.
(In reply to Kristof Provost from comment #3) You are right Kristof, I'm using pf.