Re: at SVN r347375, terminating/restarting openvpn on tap causes panic

On Thu, May 9, 2019 at 8:27 AM Michael Butler
<imb_at_protected-networks.net> wrote:
>
> On 2019-05-09 09:07, Kyle Evans wrote:
> > On Thu, May 9, 2019 at 7:24 AM Michael Butler
> > <imb_at_protected-networks.net> wrote:
> >>
> >> Seems there's a lock or tuntap issue after recent changes. Restarting
> >> openvpn (configured to use /dev/tap) yields a panic as follows:
> >>
> >
> > Ah, I knew I was forgetting something. =( Give this a shot:
> > https://people.freebsd.org/~kevans/etherdetach.diff
>
> Sorry - same result,
>
> (kgdb) bt
> #0  doadump () at src/sys/amd64/include/pcpu.h:241
> #1  0xffffffff808393c8 in kern_reboot (howto=260) at
> /usr/src/sys/kern/kern_shutdown.c:470
> #2  0xffffffff80839826 in vpanic (fmt=<value optimized out>, ap=<value
> optimized out>) at /usr/src/sys/kern/kern_shutdown.c:896
> #3  0xffffffff80839663 in panic (fmt=<value optimized out>) at
> /usr/src/sys/kern/kern_shutdown.c:823
> #4  0xffffffff80c318a6 in trap_fatal (frame=0xfffffe0072b14510, eva=156)
> at /usr/src/sys/amd64/amd64/trap.c:946
> #5  0xffffffff80c31c59 in trap_pfault (frame=0xfffffe0072b14510,
> usermode=0) at src/sys/amd64/include/cpufunc.h:423
> #6  0xffffffff80c30fde in trap (frame=0xfffffe0072b14510) at
> /usr/src/sys/amd64/amd64/trap.c:441
> #7  0xffffffff80c0d4b5 in calltrap () at
> /usr/src/sys/amd64/amd64/exception.S:232
> #8  0xffffffff80a15377 in ip_output (m=<value optimized out>, opt=<value
> optimized out>, ro=0x0, flags=0, imo=0xfffffe0072b14780, inp=0x0) at
> /usr/src/sys/netinet/ip_output.c:362
> #9  0xffffffff809ffea4 in igmp_intr (m=<value optimized out>) at
> /usr/src/sys/netinet/igmp.c:3455
> #10 0xffffffff80975a0f in netisr_dispatch_src (proto=2, source=<value
> optimized out>, m=<value optimized out>) at /usr/src/sys/net/netisr.c:1122
> #11 0xffffffff809fe07a in igmp_fasttimo () at
> /usr/src/sys/netinet/igmp.c:496
> #12 0xffffffff808c5854 in pffasttimo (arg=<value optimized out>) at
> /usr/src/sys/kern/uipc_domain.c:521
> #13 0xffffffff80853df3 in softclock_call_cc (c=0xffffffff813f7f48,
> cc=0xffffffff814c9ac0, direct=0) at /usr/src/sys/kern/kern_timeout.c:731
> #14 0xffffffff808542b9 in softclock (arg=0xffffffff814c9ac0) at
> /usr/src/sys/kern/kern_timeout.c:869
> #15 0xffffffff807fd0c4 in ithread_loop (arg=<value optimized out>) at
> /usr/src/sys/kern/kern_intr.c:1129
> #16 0xffffffff807f9f33 in fork_exit (callout=0xffffffff807fcef0
> <ithread_loop>, arg=0xfffff800025f10a0, frame=0xfffffe0072b14ac0) at
> /usr/src/sys/kern/kern_fork.c:1058
> #17 0xffffffff80c0e4ae in fork_trampoline () at
> /usr/src/sys/amd64/amd64/exception.S:995
> #18 0x0000000000000000 in ?? ()
>

Ah, I misread your backtrace (and forgot the proper tap detachment
from my previous patch, so that's fixed/committed anyways). CC'ing
Gleb for further triage as committer of r347375 that touched things in
this path.