Same DF-3486 defect reached through ng_iface (with only the DF-3485 fix
applied to ng_iface, so creation survives past ng_iface_get_unit and reaches
ng_iface's own if_attach call at ng_iface.c:605):

    # kldload /usr/obj/usr/src/sys/netgraph/iface/ng_iface.ko   (DF-3485-fixed)
    # ngctl mkpeer . iface inet inet

    panic: try holding ifnet lock in netisr
    cpuid = 0
    Trace beginning at frame 0xfffff8008d1f87e0
    ifnet_lock() at ifnet_lock+0x62 0xffffffff807304d2
    ifnet_lock() at ifnet_lock+0x62 0xffffffff807304d2
    if_attach() at if_attach+0x4db 0xffffffff80730a8b
    ng_iface_constructor() at ng_iface_constructor+0x22d 0xffffffff8265653d
    ng_mkpeer() at ng_mkpeer+0x4c 0xffffffff82618ebc
    ng_generic_msg() at ng_generic_msg+0x415 0xffffffff82619835
    Debugger("panic")

=> ng_iface.c:605 (if_attach) and ng_iface.c:800-801 (if_detach in
ng_iface_rmnode) are affected by the same context violation as
ng_eiface.c:356. The stock ng_iface never gets this far only because
DF-3485 panics first; and ng_iface_rmnode's if_detach-from-netisr was
ALREADY a latent instance of this defect in the stock code (reachable by
shutting down any successfully-created iface node).