[Oisf-devel] 答复: A thread-sync issue in suricata

李志强1(研七 福州) lizhiqiang at ruijie.com.cn
Mon Nov 17 01:29:29 UTC 2014


Hi,
   I tried, but it's seem that I haven't the right to open a bug in redmine.  Can you do it yourself?
   Thanks. 

-----邮件原件-----
发件人: Anoop Saldanha [mailto:anoopsaldanha at gmail.com] 
发送时间: 2014年11月16日 22:29
收件人: 李志强1(研七 福州)
抄送: oisf-devel at lists.openinfosecfoundation.org
主题: Re: [Oisf-devel] 答复: A thread-sync issue in suricata

Hi,

I see the issue now.  Yes, you are right.  StreamTcpInitConfig() should move before RunModeDispatch() and execute conditionally if runmode != unix_socket.

Can you please open a bug in redmine?

On Wed, Nov 12, 2014 at 6:47 AM, 李志强1(研七 福州) <lizhiqiang at ruijie.com.cn> wrote:
> Hi,
>     Thanks for your reply.
>     Maybe my last mail is ambiguous. You haven't get me yet.
>     I know all the thread init functions are run first before the module callbacks in the loop. Bug the thread-sync issue isn't between thread init functions and their callback, it's between thread init function and the main thread init phase.
>     You see:
>     1. all theads spawn and call the init functions the the new thread, and the main thead wait the child thread init done. See function TmThreadSpawn in tm-threads.c
>     2. in the main thread, the module of streamtcp init the config after all the work threads spawn. See function StreamTcpInitConfig called in suricata.c .
>
>    Above, it make the stream_config.prealloc_sessions get an uninitialized value in function StreamTcpThreadInit(the streamtcp module's init function).
>
>
>
>
> -----邮件原件-----
> 发件人: Anoop Saldanha [mailto:anoopsaldanha at gmail.com]
> 发送时间: 2014年11月11日 22:21
> 收件人: 李志强1(研七 福州)
> 抄送: oisf-devel at lists.openinfosecfoundation.org
> 主题: Re: [Oisf-devel] 答复: A thread-sync issue in suricata
>
> Hi,
>
> In workers all the init functions are run first and then the actual module callbacks in the loop.
>
> Even in non-worker modes, when they are in separate threads, we make sure that at startup, we pause all threads, till all threads are through their init phase, and only then unpause all of them, which initiates the processing per thread.
>
> On Fri, Nov 7, 2014 at 1:29 PM, 李志强1(研七 福州) <lizhiqiang at ruijie.com.cn> wrote:
>> Hi,  is there any solution for this problem?
>>
>>
>>
>> 发件人: 李志强1(研七 福州)
>> 发送时间: 2014年11月5日 11:52
>> 收件人: 'oisf-devel at lists.openinfosecfoundation.org'
>> 主题: A thread-sync issue in suricata
>>
>>
>>
>> When I review the code of suricata-2.0.1, I found there is a 
>> thread-sync issue for streamTcp module.
>>
>> The config of streamTcp parsed at function StreamTcpInitConfig in 
>> Suricata-Main.
>>
>> Bug streamTcp tread init at function StreamTcpThreadInit in 
>> capture-Thread, such as AFPacketeth21.
>>
>> If capture-thread run first after spawning, It will lead to streamTcp 
>> don’t prealloc any sessions.
>>
>> This issue don’t affect the function, but I think it will reduce 
>> performance when process tcp flow.
>>
>>
>>
>> Here is the details:
>>
>>
>>
>> 1.       my configuration:
>>
>> My config in suricata.yaml is running with workers mode and use 
>> af-packet to capture packets.
>>
>>
>>
>> 2.       StreamTcpThreadInit is called after thread spawn, it will prealloc
>> tcpsessions through PoolInit, here is the gdb stack trace:
>>
>>
>>
>> #0  PoolInit (size=0, prealloc_size=0, elt_size=192, Alloc=0x50ea30 
>> <StreamTcpSessionPoolAlloc>, Init=0x50e680 
>> <StreamTcpSessionPoolInit>, InitData=0x0,
>>
>>     Cleanup=0x50e730 <StreamTcpSessionPoolCleanup>, Free=0) at
>> util-pool.c:85
>>
>> #1  0x0000000000568b7c in PoolThreadGrow (pt=<optimized out>, size=0, 
>> prealloc_size=0, elt_size=192, Alloc=0x50ea30 
>> <StreamTcpSessionPoolAlloc>,
>>
>>     Init=0x50e680 <StreamTcpSessionPoolInit>, InitData=0x0,
>> Cleanup=0x50e730 <StreamTcpSessionPoolCleanup>, Free=0) at
>> util-pool-thread.c:116
>>
>> #2  0x000000000050e13c in StreamTcpThreadInit (tv=0x266655e0, 
>> initdata=<optimized out>, data=<optimized out>) at stream-tcp.c:4600
>>
>> #3  0x0000000000525480 in TmThreadsSlotPktAcqLoop (td=0x266655e0) at
>> tm-threads.c:669
>>
>> #4  0x00007ffff6f2ae9a in start_thread () from
>> /lib/x86_64-linux-gnu/libpthread.so.0
>>
>> #5  0x00007ffff67f93fd in clone () from
>> /lib/x86_64-linux-gnu/libc.so.6
>>
>> #6  0x0000000000000000 in ?? ()
>>
>>
>>
>> You will sess the prealloc_size is 0 even in my suricata.yaml it set 
>> to 50000.
>>
>> stream:
>>
>>    memcap: 1gb
>>
>>    checksum-validation: yes      # reject wrong csums
>>
>>    midstream: false
>>
>>   prealloc-sessions: 50000
>>
>>
>>
>> 3.       StreamTcpInitConfig is called in main thread after spawn the
>> capture thread:
>>
>> Breakpoint 2, StreamTcpInitConfig (quiet=0 '\000') at 
>> stream-tcp.c:341
>>
>> 341  {
>>
>> (gdb) bt
>>
>> #0  StreamTcpInitConfig (quiet=0 '\000') at stream-tcp.c:341
>>
>> #1  0x0000000000410d70 in main (argc=<optimized out>, argv=<optimized
>> out>) at suricata.c:2249
>>
>>
>>
>>
>> _______________________________________________
>> Suricata IDS Devel mailing list: oisf-devel at openinfosecfoundation.org
>> Site: http://suricata-ids.org | Participate:
>> http://suricata-ids.org/participate/
>> List:
>> https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-devel
>> Redmine: https://redmine.openinfosecfoundation.org/
>
>
>
> --
> -------------------------------
> Anoop Saldanha
> http://www.poona.me
> -------------------------------



--
-------------------------------
Anoop Saldanha
http://www.poona.me
-------------------------------


More information about the Oisf-devel mailing list