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

On 13 June 2010 12:12, Lawrence Stewart <lstewart_at_freebsd.org> wrote:
> Hi all,
>
> The time has come to solicit some external testing for my SIFTR tool. I'm
> hoping to commit it within a week or so unless problems are discovered.
>
> SIFTR is a kernel module that logs a range of statistics on active TCP
> connections to a log file. It provides the ability to make highly granular
> measurements of TCP connection state, aimed at system administrators,
> developers and researchers. You can use the data to find bugs in the stack,
> understand why connections are performing badly and test new code to name a
> few uses.
>
> Development has been made possible in part by grants from the Cisco
> University Research Program Fund at Community Foundation Silicon Valley, and
> the FreeBSD Foundation. Bringing it into FreeBSD proper is being carried out
> under the auspices of the "Enhancing the FreeBSD TCP Implementation" FreeBSD
> Foundation project. More details are available at [1,2,3].
>
> If you can help out, please read on!
>
> Before continuing, make sure you're running with at least svn revision
> 209119 (my commit to <sys/pcpu.h>), or you can manually apply the r209119
> diff to to your earlier rev source tree.
>
> The SIFTR patch is here:
>
> http://people.freebsd.org/~lstewart/patches/tcp_ffcaia2008/siftr_9.x.r209119.patch
>
> Copy it to the root of your source tree and run the following:
>
> patch -p1 < siftr_9.x.r209119.patch
>
> It's a loadable kernel module so you can build it for testing like so:
>
> cd <path/to/src>/sys/modules/siftr
> make
> kldload ./siftr.ko
> (don't forget to "make cleandir" to remove cruft when finished testing)
>
> After applying the patch, you can read the man page by running:
>
> man -M <path/to/src>/share/man siftr
>
> If I've done a decent job, all the info you need to understand what it does
> and how to use it should be in the man page.
>
> I'm interested in all feedback and reports of success/failure, along with
> details of the architecture tested and number of CPUs if you would be so
> kind.
>
> That should be enough to get the ball rolling. Thanks and I look forward to
> hearing from you!
>
> Cheers,
> Lawrence
>
> [1] http://caia.swin.edu.au/freebsd/etcp09/
>
> [2] http://www.freebsdfoundation.org/projects.shtml#Swinburne
>
> [3] http://caia.swin.edu.au/urp/newtcp/

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

-- 
wbr,
pluknet