rtentry panic with FIB

[Julian Elischer]

John Baldwin wrote:
> Unfortunately it hung trying to dump, so all I have is the stack trace from 
> DDB.  This is recent HEAD running stress2
> 
> panic: _mtx_lock_sleep: recursed on non-recursive mutex rtentry @ ../../1
> 

do you know what lock it was talking about?
rt_check_fib is not really any different from what it was before
in general the multi routing table code shouldn't add any locking 
paths that were not already present.
I think there is some hint of a problem in the interaction of mrt and 
arp however so I think I need to re-visit that code.. (It's all
flushed out of my brain-cache at the moment).


> cpuid = 1
> KDB: enter: panic
> [thread pid 14025 tid 100928 ]
> Stopped at      kdb_enter+0x3d: movq    $0,0x435054(%rip)
> db> tr
> Tracing pid 14025 tid 100928 td 0xffffff0003773360
> kdb_enter() at kdb_enter+0x3d
> panic() at panic+0x14b
> _mtx_lock_flags() at _mtx_lock_flags
> _mtx_lock_flags() at _mtx_lock_flags+0xc3
> rt_check_fib() at rt_check_fib+0x1ea
> arpresolve() at arpresolve+0x77
> ether_output() at ether_output+0x180
> ip_output() at ip_output+0xb4f
> udp_send() at udp_send+0x47d
> sosend_dgram() at sosend_dgram+0x1fa
> soo_write() at soo_write+0x30
> dofilewrite() at dofilewrite+0x7a
> kern_writev() at kern_writev+0x52
> write() at write+0x4d
> syscall() at syscall+0x1bf
> Xfast_syscall() at Xfast_syscall+0xab
> --- syscall (4, FreeBSD ELF64, write), rip = 0x80071cb7c, rsp = 
> 0x7fffffffe628,-
> db> c
> Uptime: 1h39m18s
> Physical memory: 2038 MB
> Dumping 263 MB:pid 14025 (udp), uid 26840, was killed: exceeded maximum CPU 
> limt
> pid 14099 (udp), uid 26840, was killed: exceeded maximum CPU limit
> pid 14100 (udp), uid 26840, was killed: exceeded maximum CPU limit
>