Bug 159815 - kernel panic when using QUEUE target with iptables
kernel panic when using QUEUE target with iptables
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel (Show other bugs)
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Thomas Graf
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2005-06-08 05:33 EDT by Ilkka Pietikäinen
Modified: 2014-06-18 04:28 EDT (History)
4 users (show)

See Also:
Fixed In Version: U4
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-06-21 18:39:14 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Test program to recreate the issue. (5.40 KB, text/plain)
2005-07-15 15:07 EDT, Wendy Cheng
no flags Details

  None (edit)
Description Ilkka Pietikäinen 2005-06-08 05:33:07 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050513 Firefox/1.0.4

Description of problem:
When running our application, the kernel will give following panic (with kernel 2.6.9-5.EL):

Kernel panic - not syncing: net/ipv4/tcp_timer.c:211: spin_lock(net/ipv4/tcp_minisocks.c:e36dc0a0) already locked by net/ipv4/tcp_ipv4.c/1790

With SMP kernel (2.6.9-5.EL) the system hangs completely (will not take input from the console) and will not give any kernel panic message.

Our application uses QUEUE target with iptables to handle packet filtering in user space. It also uses TCP/UDP/multicast sockets and is quite CPU extensive. Our application is completely user space stuff.

This happens an all EL4 systems we have tried. Does not happen with EL3 or other 2.6.X kernel based distros we have tried.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Start the application
2. After few minutes to few hours the system stops responding


Actual Results:  Kernel panic or system hangs completely

Expected Results:  System should stay responsive

Additional info:

Similar bug entered for FC3:

Comment 1 David Miller 2005-06-21 18:26:06 EDT
James, as author of the QUEUE iptables code could you take a quick
look at this one?  By far, the one constant is that everyone seeing
this bug is using QUEUE.

There also seems to be no indication that TUX is being used, but it
would be nice for the bug reporter to tell if they are in fact using
TUX as that adds yet another variable.
Comment 2 Ilkka Pietikäinen 2005-06-22 03:08:41 EDT
TUX is not used when this happens.
Comment 4 Wendy Cheng 2005-07-15 15:07:18 EDT
Created attachment 116818 [details]
Test program to recreate the issue.
Comment 5 James Morris 2005-07-24 01:46:58 EDT
(In reply to comment #1)

I gather it's this (patch upstream and also in url):

Comment 6 Ilkka Pietikäinen 2005-08-22 05:44:39 EDT
Is the patch (mentioned by James) included in any RH4 kernels?
Comment 7 James Morris 2005-08-22 05:53:40 EDT
It's in current RHEL4 kernel cvs, so it should be available in the U2 kernel to
be released very soon.
Comment 8 Ilkka Pietikäinen 2005-09-01 05:58:55 EDT
We have now done two days of testing with 2.6.9-11 kernel that is patched with
the given patch. The system is more stable but it has had panic three times with
the messege:

Kernel panic - not syncing: Fatal exception in interrupt

Part of the stack trace (handwritten so may contain some typos):


We are trying to collect more information using netdump utility. But if anybody
has any ideas, those are welcome.

Comment 9 Ilkka Pietikäinen 2005-09-07 03:35:28 EDT
I submitted a new bug about the case with the patched kernel

Comment 10 Ilkka Pietikäinen 2005-10-19 08:17:12 EDT
I just checked the 2.6.9-22 and I did not found the patch (I found the patch for
IPv6 though). Does anyone have information in which version this is included?
Comment 12 Linda Wang 2006-06-23 18:23:28 EDT
The issue you encountered may be fixed in U4 public beta kernel. 
Can you please give it a try, and post your results here? 

many thanks.

Note You need to log in before you can comment on or make changes to this bug.