Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 159815 - kernel panic when using QUEUE target with iptables
Summary: kernel panic when using QUEUE target with iptables
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel
Version: 4.0
Hardware: i386
OS: Linux
medium
high
Target Milestone: ---
: ---
Assignee: Thomas Graf
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-06-08 09:33 UTC by Ilkka Pietikäinen
Modified: 2014-06-18 08:28 UTC (History)
4 users (show)

Fixed In Version: U4
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-06-21 22:39:14 UTC


Attachments (Terms of Use)
Test program to recreate the issue. (deleted)
2005-07-15 19:07 UTC, Wendy Cheng
no flags Details

Description Ilkka Pietikäinen 2005-06-08 09:33:07 UTC
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):
kernel-2.6.9-5.EL

How reproducible:
Always

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:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=147750

Comment 1 David Miller 2005-06-21 22:26:06 UTC
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 07:08:41 UTC
TUX is not used when this happens.

Comment 4 Wendy Cheng 2005-07-15 19:07:18 UTC
Created attachment 116818 [details]
Test program to recreate the issue.

Comment 5 James Morris 2005-07-24 05:46:58 UTC
(In reply to comment #1)

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

https://lists.netfilter.org/pipermail/netfilter-devel/2005-July/020513.html

Comment 6 Ilkka Pietikäinen 2005-08-22 09:44:39 UTC
Is the patch (mentioned by James) included in any RH4 kernels?

Comment 7 James Morris 2005-08-22 09:53:40 UTC
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 09:58:55 UTC
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):

syscall_call
sys_gettimeofday
sys_socketcall
do_IRQ
handle_IRQ_event
tg3_interrupt
move_addr_to_usr
sys_sendmsg
verify_iovec
autoremove_woke_function
sock_recvmsg
netlink_recvmsg
sock_sendmsg
__wake_up
netlink_sendmsg
netlink_sendskb
netlink_data_ready
ipq_rec_sk
ipq_receive_peer

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 07:35:28 UTC
I submitted a new bug about the case with the patched kernel

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=167389

Comment 10 Ilkka Pietikäinen 2005-10-19 12:17:12 UTC
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 22:23:28 UTC
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.