Bug #1714
closedKernel panic on application exit with netmap Suricata 3.0 stable
Description
I've got kernel panic on application exit when I use netmap to capture traffic in IDS mode.
The problem is in NetmapClose function, in the rings freeing order. Changing the order to make NR_REG_SW ring to free first solves the problem.
Patch attached.
Files
Updated by Victor Julien over 8 years ago
If you submit it as git patch you can become part of the git history.
Updated by Victor Julien over 8 years ago
- Status changed from New to Assigned
- Assignee set to Aleksey Katargin
- Target version changed from 3.0.1RC1 to 70
Aleksey, are you able to have a look at this?
Updated by Aleksey Katargin over 8 years ago
Vadim, which netmap and OS version do you use? Could you submit any kind of kernel panic info?
It seems to me it could be a bug in netmap, cuz order must not be important.
Updated by Vadim Fedorenko over 8 years ago
Well, I'm using CentOS 6.7 based Linux with 4.1.16 kernel built from elrepo spec and the latest git netmap. I've opened netmap ticket also.
Updated by Peter Manev over 8 years ago
Vadim - can you please share the compile/install steps that you did for netmap (I would like to run a short cross ref on 3.16 and 4.4 kernel). Thanks.
Updated by Vadim Fedorenko over 8 years ago
So, compile/install steps for netmap:
git clone https://github.com/luigirizzo/netmap.git cd netmap/LINUX ./configure --kernel-sources=~/src/linux-4.1.16/ --drivers=ixgbe make make install
Assuming src/linux-4.1.16 is a linux kernel source tree.
Then rmmod ixgbe && modprobe ixgbe - this loads ixgbe module with netmap module as dependency.
For suricata:
./configure --enable-libnet --enable-af-packet --enable-netmap --enable-pie --enable-gcc-march-native --prefix=/usr/ --sysconfdir=/etc/ --localstatedir=/var/ make install && make install-conf
To properly start listening on eth1:
ethtool -K eth1 tso off tx off sg off && ethtool -G eth1 rx 4096 tx 4096 && ethtool -A eth1 rx off tx off echo 66000 > /sys/module/netmap/parameters/ring_size suricata --netmap=eth1
Such behavior reproduces with default config and no rules loaded.
Updated by Aleksey Katargin over 8 years ago
Vadim, can you you test suricata with this netmap version?
https://github.com/luigirizzo/netmap/commit/60d516a6e4385f8e2a768ea48e5214eea614da4e
Updated by Vadim Fedorenko over 8 years ago
Aleksey,
The version of netmap i've used includes this commit.
As I said before, I've use git clone netmap.git to get the latest version from github.
Updated by Aleksey Katargin over 8 years ago
Vadim,
I know that this commit is included in the master branch of netmap.
If this issue is related with latest changes in netmap, you can try older version and figure this out and then use git bisect to address bogus commit.
In our production systems (not suricata) we tried to use more recent netmap version, but sometimes we got failures with it.
Updated by Vadim Fedorenko over 8 years ago
Aleksey,
Ok, I'll try. I have another instance with Suricata 2.1beta4 with netmap support and netmap version at 31.03.2015. I'll update this instance to Suricata 3.0 without updating netmap. I'll write feedback soon.
Updated by Vadim Fedorenko over 8 years ago
Aleksey,
Well, on linux-3.19.3 with netmap version at 31.03.2015 everything seems to be OK. I'll try to examine netmap's source code changes to understand what's went wrong. The ticket in netmap's github repo is opened, #144
Updated by Aleksey Katargin over 8 years ago
This may be helpful for you https://git-scm.com/book/en/v2/Git-Tools-Debugging-with-Git
Updated by Vadim Fedorenko over 8 years ago
While Netmap ticket is in investigation I think we can use the patch to work with latest netmap. The pull request was send via email.
Updated by Victor Julien over 8 years ago
Updated by Victor Julien over 8 years ago
- Status changed from Assigned to Closed
- Target version changed from 70 to 3.1rc1