panic: try holding ifnet lock in netisr
cpuid = 0
Trace beginning at frame 0xfffff8008d1f87b0
ifnet_lock() at ifnet_lock+0x62 0xffffffff807304d2
ifnet_lock() at ifnet_lock+0x62 0xffffffff807304d2
if_attach() at if_attach+0x4db 0xffffffff80730a8b
ether_ifattach_bpf() at ether_ifattach_bpf+0x45 0xffffffff80739e35
ng_eiface_constructor() at ng_eiface_constructor+0xf6 0xffffffff826912f6
ng_mkpeer() at ng_mkpeer+0x4c 0xffffffff82618ebc
Debugger("panic")

CPU0 stopping CPUs: 0x0000003e
 stopped
Stopped at      Debugger+0x7c:  movb    $0,0xbdaf09(%rip)
db>

--------------------------------------------------------------------------
Captured from the DF-3495 verification session: while attempting to build
a genuinely-parallel (non-cpu0) data path for the ng_l2tp hook-UAF PoC,
the eiface variant (l2tp_hook_uaf_eiface.c) creates an ng_eiface node via
a netgraph control message (ng_mkpeer).  All ng_socket control messages
execute on cpu0's netisr thread; ng_eiface_constructor() calls
ether_ifattach() -> if_attach() -> ifnet_lock(), which KASSERTs against
netisr context (sys/net/if.c:3787).  Deterministic panic on INVARIANTS
kernels; this is the already-filed DF-3486 (pass 1), re-confirmed here.
Relevant to DF-3495 only because it forecloses the eiface route to a
concurrent lower-hook feeder on this guest.