Re: [CFT] SIFTR - Statistical Information For TCP Research

From: Lawrence Stewart <lstewart_at_freebsd.org>
Date: Sun, 20 Jun 2010 02:22:46 +1000
Hi Pluknet,

On 06/19/10 18:48, pluknet wrote:
[snip]
> Hi.
>
> I'm seeing this right after enabling siftr via sysctl and changing ppl.
> Sorry, if that was already discussed, known or unrelated (since em is
> in locking chain).
>
> lock order reversal:
>   1st 0xffffffff80e51568 PFil hook read/write mutex (PFil hook
> read/write mutex) _at_ /usr/src/sys/net/pfil.c:77
>   2nd 0xffffffff80e52788 tcp (tcp) _at_
> /usr/src/sys/modules/siftr/../../netinet/siftr.c:698
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
> _witness_debugger() at _witness_debugger+0x2e
> witness_checkorder() at witness_checkorder+0x81e
> _rw_rlock() at _rw_rlock+0x5f
> siftr_chkpkt() at siftr_chkpkt+0x374
> pfil_run_hooks() at pfil_run_hooks+0xcf
> ip_input() at ip_input+0x2ae
> netisr_dispatch_src() at netisr_dispatch_src+0xb8
> ether_demux() at ether_demux+0x17d
> ether_input() at ether_input+0x175
> em_rxeof() at em_rxeof+0x193
> em_handle_que() at em_handle_que+0x4a
> taskqueue_run() at taskqueue_run+0x91
> taskqueue_thread_loop() at taskqueue_thread_loop+0x3f
> fork_exit() at fork_exit+0x12a
> fork_trampoline() at fork_trampoline+0xe
> --- trap 0, rip = 0, rsp = 0xffffff80000bed30, rbp = 0 ---

I believe I discussed this LOR with Robert Watson some time back and we 
came to the conclusion it is a false positive witness report and is safe 
to ignore. I should document it in the man page and figure out if 
there's some way to tell witness to not report it. Thanks for reminding 
me and for testing. Did everything else behave sanely and work ok?

Cheers,
Lawrence
Received on Sat Jun 19 2010 - 14:22:49 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:04 UTC