Panic when destroying interfaces (kern/116837?)

When investigating panics when destroying bridge(4) and tap(4) interfaces,
I'm receiving a panic suspiciously similar to what I was seeing with ural(4)
and wpa_supplicant(8).

(It's likely that I'm seeing two separate issues with ural(4), but only
investigated the one triggered when removing one of the devices.)

Looking at the panic I receive with ural:

: -----
: panic: _rw_rlock (radix node head): wlock already held _at_ /repo/freebsd/8-CURRENT/src/sys/net/route.c: 291
: -----

I see exactly the same message when destroying bridge(4) and tap(4) virtual
interfaces:

-----
# kldload if_bridge
# ifconfig bridge0 create
bridge0: Ethernet address: e6:02:10:1c:bc:22
# ifconfig bridge0 destroy

panic: _rw_rlock (radix node head): wlock already held _at_ /repo/freebsd/8-CURRENT/src/sys/net/route.c: 291
-----

The actual panic is exactly the same for bridge(4) and tap(4), save two
specific lines.  Here's a bridge(4) dump, copied by hand, as I was unable to
coax db into a dump (pid 47662 is ifconfig):

-----
cpuid = 1
KDB: enter: panic
[thread pid 47662 tid 100145]
Stopped at      kdb_enter+0x3d: movq     $0:0xb2d8c5(%rip)
db> where
Tracing pid 47662 tid 100145 td 0xffffff000a02a000
kdb_enter() at kdb_enter+0x3d
panic() at panic+0x1c8
_rw_rlock() at _rw_rlock+0x78
rtalloc1_fib() at rtalloc1_fib+0x4c
rtalloc1() at rtalloc1+0xe
in6_ifdetach() at in6_ifdetach+0x45d
if_detach() at if_detach+0x112
ether_ifdetach() at ether_ifdetach+0x41
bridge_clone_destroy() at bridge_clone_destroy+0x125
ifc_simple_destroy() at ifc_simple_destroy+0x22
if_clone_destroyif() at if_clone_destroyif+0xde
if_clone_destroy() at if_clone_destroy+0x8d
ifioctl() at ifioctl+0x10e
soo_ioctl() at soo_ioctl+0x33f
kern_ioctl() at kern_ioctl+0x1a5
ioctl() at ioctl()+0x158
syscall() at syscall()+0x2e9
Xfast_syscall() at Xfast_syscall+0xab
--- syscall (54, FreeBSD ELF64, ioctl), rip = 0x800a5a09c, rsp = 0x7fffffffe398, rbp = 0x7fffffffee29 ---
-----

The two lines that change with a tap(4) panic are the lines starting,
"bridge_clone_destroy" and "--- sysctall".  They are, instead:

-----
tap_destroy() at tap_destroy+0x2d

--- syscall (54, FreeBSD ELF64, ioctl), rip = 0x800a5a09c, rsp = 0x7fffffffe398, rbp = 0x7fffffffee2e ---
-----

After taking a better look through the PR database, this seems to be the
same thing as kern/116837, which hasn't been touched since February.  I'll
be taking a look at the proposed patch to see if I can modify it for
bridge(4) and tap(4), unless there's something bigger going on, as this
seems to affect a number of different interface types: at least bridge(4)
and tap(4); possibly ural(4) and wlan(4) as well.

  - Damian