locking against myself, mbuf was already freed (was: repeated network-related panics/lock-ups on 8.1)

[Edgar Fuß <ef%math.uni-bonn.de@localhost>]

> It looks that a server of mine will consistently lock up or panic as soon as 
> I run an Icinga 2 master on it (which will fork /a lot/).
Good news: I built a DIAGNOSTIC+DEBUG+LOCKDEBUG kernel and now I don't even 
need Icinga 2 to run any more to make it panic.

1. mbuf was already freed at nd6_resolve,2351
breakpoint
vpanic
snprintf
m_prepend
ipf_fastroute
ipf_send_ip
ipf_check
pfil_run_hooks
ip6_input
ip6intr
softint_dispatch

2. LOCKDEBUG: Reader / writer lock error: rw_vector_enter,291: locking against myself

lock address : 0xffffffff80a89c08 type :         sleep/adaptive
initialized  : 0xffffffff8040bb31
shared holds :                  1 exclusive:                  0
shares wanted:                  1 exclusive:                  0
current cpo  :                  0 last held:                  0
current lwp  : 0xfffffe841de11420 last held: 0xfffffe841de11420
last locked  : 0xffffffff804092d0 unlocked*: 0xffffffff804091dd
owner/count  : 0x0000000000000010 flags    : 000000000000000000

breakpoint
vpanic
snprintf
lockdebug_more
rw_enter
ipf_check
pfil_run_hooks
ip6_output
nd6_ns_output.part.2
nd6_resolve
ether_output
ipf_if_output
ipf_fastroute
ipf_send_ip
ipf_check
pfil_run_hooks
ip6_input
ip6intr
softint_dispatch

3. Exact same panic again.

I currently leave the machine in ddb of that panic, in case I should 
investigate more.
Is the problem pfil_run_hooks() being callt recursively?