ip_queue freeze with 2.6.9 RHEL4

ip_queue freeze with 2.6.9 RHEL4

[Eric Leblond]

Hi,

I've found a reproductible kernel freeze on RHEL 4.

The method is the following. I use nufw 1.0.10 (http://www.nufw.org/) to
send an accept decision to ip_queue (Same nufw version works well on all
other systems). This is enough to freeze the computer in most cases. If
the freeze has not occured, then nufw process is a zombie. We can then
achieve a freeze by doing rmmod ip_queue.

I've tested redhat provided kernels 2.6.9-5 and 2.6.9-11 (SMP or not).
Servers are bi Xeon based computer, working well and already used by
other people for intensive testing on non-firewall tasks.

Is there known issues on some systems with 2.6.9 and ip_queue ? or is it
a RedHat problem ?

As I've used home build 2.6.9 with nufw quiet a long time on other
systems without problem, I think it could be related to RedHat
modifications of the kernel.

BR,
-- 
Eric Leblond <eric@inl.fr>

Re: ip_queue freeze with 2.6.9 RHEL4

[Patrick McHardy]

Eric Leblond wrote:
> Is there known issues on some systems with 2.6.9 and ip_queue ? or is it
> a RedHat problem ?

In which hook are you queueing packets? Does it freeze immediately, or
do you need to reinject the packet first?

Re: ip_queue freeze with 2.6.9 RHEL4

[Eric Leblond]

Le mercredi 20 juillet 2005 à 23:42 +0200, Patrick McHardy a écrit :
> Eric Leblond wrote:
> > Is there known issues on some systems with 2.6.9 and ip_queue ? or is it
> > a RedHat problem ?
> 
> In which hook are you queueing packets? 

I've got one rule only :
	iptables -A INPUT -p tcp --dport 22 --syn -j ACCEPT

Same "ruleset" works correctly with test done with RHEL3 the same day
(almost same hardware) 

> Does it freeze immediately, or
> do you need to reinject the packet first?

It freezes just after I send the NF_ACCEPT decision.

BR,
-- 
Eric Leblond <eric@inl.fr>

Re: ip_queue freeze with 2.6.9 RHEL4

[Patrick McHardy]

[-- Attachment #1: Type: text/plain, Size: 250 bytes --]

Eric Leblond wrote:
> I've got one rule only :
> 	iptables -A INPUT -p tcp --dport 22 --syn -j ACCEPT
>
> It freezes just after I send the NF_ACCEPT decision.

This looks like a problem we've already fixed in current kernels. Please
try this patch.


[-- Attachment #2: x --]
[-- Type: text/plain, Size: 2495 bytes --]

[NETFILTER]: Fix deadlock with ip_queue and tcp local input path.

When we have ip_queue being used from LOCAL_IN, then we end up with a
situation where the verdicts coming back from userspace traverse the TCP
input path from syscall context.  While this seems to work most of the
time, there's an ugly deadlock:

syscall context is interrupted by the timer interrupt.  When the timer
interrupt leaves, the timer softirq get's scheduled and calls
tcp_delack_timer() and alike.  They themselves do bh_lock_sock(sk),
which is already held from somewhere else -> boom.

I've now tested the suggested solution by Patrick McHardy and Herbert Xu to
simply use local_bh_{en,dis}able().

Signed-off-by: Harald Welte <laforge@netfilter.org>
Signed-off-by: David S. Miller <davem@davemloft.net>

---
commit 9bb7bc942d3da606f184ac6a4dfc7e4d470c831b
tree dc310200df5988d4c71c346baad6a923a4bdeb9d
parent 5e485b7975472ba4a408523deb6541e70c451842
author Harald Welte <laforge@netfilter.org> Mon, 30 May 2005 15:35:26 -0700
committer David S. Miller <davem@davemloft.net> Mon, 30 May 2005 15:35:26 -0700

 net/ipv4/netfilter/ip_queue.c |   10 ++++++++++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/net/ipv4/netfilter/ip_queue.c b/net/ipv4/netfilter/ip_queue.c
--- a/net/ipv4/netfilter/ip_queue.c
+++ b/net/ipv4/netfilter/ip_queue.c
@@ -3,6 +3,7 @@
  * communicating with userspace via netlink.
  *
  * (C) 2000-2002 James Morris <jmorris@intercode.com.au>
+ * (C) 2003-2005 Netfilter Core Team <coreteam@netfilter.org>
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License version 2 as
@@ -17,6 +18,7 @@
  * 2005-01-10: Added /proc counter for dropped packets; fixed so
  *             packets aren't delivered to user space if they're going 
  *             to be dropped. 
+ * 2005-05-26: local_bh_{disable,enable} around nf_reinject (Harald Welte)
  *
  */
 #include <linux/module.h>
@@ -71,7 +73,15 @@ static DECLARE_MUTEX(ipqnl_sem);
 static void
 ipq_issue_verdict(struct ipq_queue_entry *entry, int verdict)
 {
+	/* TCP input path (and probably other bits) assume to be called
+	 * from softirq context, not from syscall, like ipq_issue_verdict is
+	 * called.  TCP input path deadlocks with locks taken from timer
+	 * softirq, e.g.  We therefore emulate this by local_bh_disable() */
+
+	local_bh_disable();
 	nf_reinject(entry->skb, entry->info, verdict);
+	local_bh_enable();
+
 	kfree(entry);
 }