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, LawrenceReceived 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