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 0xffffffff826562f6 
ng_mkpeer() at ng_mkpeer+0x4c 0xffffffff82618ebc 
Debugger("panic")

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

---------------------------------------------------------------------------
Captured live from the serial console (dfbsd-qemu/boot.log) on 2026-09-13,
fresh boot, stock kernel + stock /boot/kernel/ng_eiface.ko, trigger:

    # kldload ng_socket ng_eiface
    # ngctl mkpeer . eiface e0 ether

Deterministic (first-try on every boot). ng_eiface_constructor+0xf6 is the
instruction after the `callq ether_ifattach` at +0xf1 (DWARF maps 0x2f1/0x2f6
to ng_eiface.c:356); ether_ifattach() -> ether_ifattach_bpf() -> if_attach()
(sys/net/if_ethersubr.c:622) -> ifnet_lock() (sys/net/if.c:3787):

    KASSERT(curthread->td_type != TD_TYPE_NETISR,
        ("try holding ifnet lock in netisr"));

Netgraph control messages execute on a TD_TYPE_NETISR thread (the AF_NETGRAPH
socket protocol thread), so no netgraph node constructor may call
if_attach()/ether_ifattach().  Independently of the KASSERT, if_attach()
calls netmsg_service_sync() (sys/net/if.c:741), which cannot run from a
netisr thread (it would wait for itself) — i.e. on non-INVARIANTS kernels
this defect degrades from clean panic to a self-deadlock/hang.

NOTE: the DF-3482 lead recorded this panic as "trying to free NULL pointer
at ng_eiface_constructor+0xf6"; that message was extrapolated from a
truncated console window. The full, first-hand capture above is the actual
signature and is a different defect from DF-3485 (ng_eiface has no
ng_iface_units bitmap).