linux-rt-users.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [BUG] 2.6.33.2-rt13 and iptables
@ 2010-04-25 17:55 FC
  2010-04-27  8:13 ` Thomas Gleixner
  0 siblings, 1 reply; 3+ messages in thread
From: FC @ 2010-04-25 17:55 UTC (permalink / raw)
  To: linux-rt-users

- Updated Debian SID x86 32 bit
- kernel 2.6.33.2-rt13
- iptables v1.4.6

I've experimented some problems while displaying processed packets by 
iptables ( iptables -L -n -v ). The output displays a large number of 
processed packets with a very low network activity in my LAN ( max 1 
hundred of packets delivered )

A sample output obtained after loading iptables rules and quite 
immediately running iptables -L -n -v


Chain bad_packets (1 references)
  pkts bytes target     prot opt in     out     source destination
8600M 15024815T LOG        all  --  *      *       0.0.0.0/0 0.0.0.0/0 
        state INVALID LOG flags 0 level 4 prefix `fp=bad_packets:1 a=DROP '
15024815T 15066474T DROP       all  --  *      *       0.0.0.0/0 
0.0.0.0/0           state INVALID
13777492T 15024815T bad_tcp_packets  tcp  --  *      *       0.0.0.0/0 
        0.0.0.0/0
1337099T 7793M RETURN     all  --  *      *       0.0.0.0/0 0.0.0.0/0

Chain bad_tcp_packets (1 references)
  pkts bytes target     prot opt in     out     source destination
4295M     0 LOG        tcp  --  *      *       0.0.0.0/0 0.0.0.0/0 tcp 
flags:!0x17/0x02 state NEW LOG flags 0 level 4 prefix 
`fp=bad_tcp_packets:1 a=DROP '
41659T 288230T DROP       tcp  --  *      *       0.0.0.0/0 0.0.0.0/0 
     tcp flags:!0x17/0x02 state NEW
41659T 257832T LOG        tcp  --  *      *       0.0.0.0/0 0.0.0.0/0 
     tcp flags:0x3F/0x00 LOG flags 0 level 4 prefix 
`fp=bad_tcp_packets:2 a=DROP '
41659T 144115T DROP       tcp  --  *      *       0.0.0.0/0 0.0.0.0/0 
     tcp flags:0x3F/0x00
41659T 352428T LOG        tcp  --  *      *       0.0.0.0/0 0.0.0.0/0 
     tcp flags:0x3F/0x3F LOG flags 0 level 4 prefix 
`fp=bad_tcp_packets:3 a=DROP '
72059T 13835076T DROP       tcp  --  *      *       0.0.0.0/0  0.0.0.0/0 
           tcp flags:0x3F/0x3F
72059T 15024832T LOG        tcp  --  *      *       0.0.0.0/0  0.0.0.0/0 
           tcp flags:0x3F/0x29 LOG flags 0 level 4 prefix 
`fp=bad_tcp_packets:4 a=DROP '
113717T 72074T DROP       tcp  --  *      *       0.0.0.0/0 0.0.0.0/0 
     tcp flags:0x3F/0x29
72059T  155G LOG        tcp  --  *      *       0.0.0.0/0 0.0.0.0/0 
tcp flags:0x3F/0x37 LOG flags 0 level 4 prefix `fp=bad_tcp_packets:5 
a=DROP '
3498M     0 DROP       tcp  --  *      *       0.0.0.0/0 0.0.0.0/0 tcp 
flags:0x3F/0x37
     0   15T LOG        tcp  --  *      *       0.0.0.0/0 0.0.0.0/0 
tcp flags:0x06/0x06 LOG flags 0 level 4 prefix `fp=bad_tcp_packets:6 
a=DROP '
72059T 4305M DROP       tcp  --  *      *       0.0.0.0/0 0.0.0.0/0 
tcp flags:0x06/0x06
15024815T 8600M LOG        tcp  --  *      *       0.0.0.0/0 0.0.0.0/0 
        tcp flags:0x03/0x03 LOG flags 0 level 4 prefix 
`fp=bad_tcp_packets:7 a=DROP '
15024815T 15024815T DROP       tcp  --  *      *       0.0.0.0/0 
0.0.0.0/0           tcp flags:0x03/0x03
15066474T 15782 RETURN     tcp  --  *      *       0.0.0.0/0 0.0.0.0/0

The problem doesn't occur with other kernels ( vanilla 2.6.33.2 , 
2.6.33-zen1 ) and the number of processed packets is displayed correctly.


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [BUG] 2.6.33.2-rt13 and iptables
  2010-04-25 17:55 [BUG] 2.6.33.2-rt13 and iptables FC
@ 2010-04-27  8:13 ` Thomas Gleixner
  2010-04-27 17:03   ` FC
  0 siblings, 1 reply; 3+ messages in thread
From: Thomas Gleixner @ 2010-04-27  8:13 UTC (permalink / raw)
  To: FC; +Cc: linux-rt-users

On Sun, 25 Apr 2010, FC wrote:

> - Updated Debian SID x86 32 bit
> - kernel 2.6.33.2-rt13
> - iptables v1.4.6
> 
> I've experimented some problems while displaying processed packets by
> iptables ( iptables -L -n -v ). The output displays a large number of
> processed packets with a very low network activity in my LAN ( max 1 hundred
> of packets delivered )
> 
> A sample output obtained after loading iptables rules and quite immediately
> running iptables -L -n -v

Can you please test the patch below on top of -rt ?

Thanks,

	tglx

---------->
Subject: net-fix-iptables-fallout.patch
From: Thomas Gleixner <tglx@linutronix.de>
Date: Tue, 27 Apr 2010 10:05:28 +0200

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
 net/ipv4/netfilter/ip_tables.c  |    9 +++++----
 net/ipv6/netfilter/ip6_tables.c |   10 +++++-----
 2 files changed, 10 insertions(+), 9 deletions(-)

Index: linux-2.6-tip/net/ipv4/netfilter/ip_tables.c
===================================================================
--- linux-2.6-tip.orig/net/ipv4/netfilter/ip_tables.c
+++ linux-2.6-tip/net/ipv4/netfilter/ip_tables.c
@@ -907,7 +907,7 @@ get_counters(const struct xt_table_info 
 {
 	unsigned int cpu;
 	unsigned int i;
-	unsigned int curcpu = NR_CPUS;
+	unsigned int curcpu;
 
 	/* Instead of clearing (by a previous call to memset())
 	 * the counters and using adds, we set the counters
@@ -917,16 +917,17 @@ get_counters(const struct xt_table_info 
 	 * if new softirq were to run and call ipt_do_table
 	 */
 	local_bh_disable();
-#ifndef CONFIG_PREEMPT_RT
-	curcpu = smp_processor_id();
+	curcpu = raw_smp_processor_id();
 
 	i = 0;
+	xt_info_wrlock(curcpu);
 	IPT_ENTRY_ITERATE(t->entries[curcpu],
 			  t->size,
 			  set_entry_to_counter,
 			  counters,
 			  &i);
-#endif
+	xt_info_wrunlock(curcpu);
+
 	for_each_possible_cpu(cpu) {
 		if (cpu == curcpu)
 			continue;
Index: linux-2.6-tip/net/ipv6/netfilter/ip6_tables.c
===================================================================
--- linux-2.6-tip.orig/net/ipv6/netfilter/ip6_tables.c
+++ linux-2.6-tip/net/ipv6/netfilter/ip6_tables.c
@@ -939,7 +939,7 @@ get_counters(const struct xt_table_info 
 {
 	unsigned int cpu;
 	unsigned int i;
-	unsigned int curcpu = NR_CPUS;
+	unsigned int curcpu;
 
 	/* Instead of clearing (by a previous call to memset())
 	 * the counters and using adds, we set the counters
@@ -949,17 +949,17 @@ get_counters(const struct xt_table_info 
 	 * if new softirq were to run and call ipt_do_table
 	 */
 	local_bh_disable();

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [BUG] 2.6.33.2-rt13 and iptables
  2010-04-27  8:13 ` Thomas Gleixner
@ 2010-04-27 17:03   ` FC
  0 siblings, 0 replies; 3+ messages in thread
From: FC @ 2010-04-27 17:03 UTC (permalink / raw)
  To: linux-rt-users

On 27/04/2010 10:13, Thomas Gleixner wrote:
> On Sun, 25 Apr 2010, FC wrote:
>
>> - Updated Debian SID x86 32 bit
>> - kernel 2.6.33.2-rt13
>> - iptables v1.4.6
>>
>> I've experimented some problems while displaying processed packets by
>> iptables ( iptables -L -n -v ). The output displays a large number of
>> processed packets with a very low network activity in my LAN ( max 1 hundred
>> of packets delivered )
>>
>> A sample output obtained after loading iptables rules and quite immediately
>> running iptables -L -n -v
>
> Can you please test the patch below on top of -rt ?
>
> Thanks,
>
> 	tglx
>

The problem doesn't occur with kernel 2.6.33.3-rt14 which includes your 
patch.

The same sample output displayed under the same conditions ( loading 
rules , typing iptables -L -n -v )

Chain bad_packets (1 references)
  pkts bytes target     prot opt in     out     source 
destination
     0     0 LOG        all  --  *      *       0.0.0.0/0 
0.0.0.0/0           state INVALID LOG flags 0 level 4 prefix 
`fp=bad_packets:1 a=DROP '
     0     0 DROP       all  --  *      *       0.0.0.0/0 
0.0.0.0/0           state INVALID
   316 21488 bad_tcp_packets  tcp  --  *      *       0.0.0.0/0 
    0.0.0.0/0
   317 21635 RETURN     all  --  *      *       0.0.0.0/0 
0.0.0.0/0

Chain bad_tcp_packets (1 references)
  pkts bytes target     prot opt in     out     source 
destination
     0     0 LOG        tcp  --  *      *       0.0.0.0/0 
0.0.0.0/0           tcp flags:!0x17/0x02 state NEW LOG flags 0 level 4 
prefix `fp=bad_tcp_packets:1 a=DROP '
     0     0 DROP       tcp  --  *      *       0.0.0.0/0 
0.0.0.0/0           tcp flags:!0x17/0x02 state NEW
     0     0 LOG        tcp  --  *      *       0.0.0.0/0 
0.0.0.0/0           tcp flags:0x3F/0x00 LOG flags 0 level 4 prefix 
`fp=bad_tcp_packets:2 a=DROP '
     0     0 DROP       tcp  --  *      *       0.0.0.0/0 
0.0.0.0/0           tcp flags:0x3F/0x00
     0     0 LOG        tcp  --  *      *       0.0.0.0/0 
0.0.0.0/0           tcp flags:0x3F/0x3F LOG flags 0 level 4 prefix 
`fp=bad_tcp_packets:3 a=DROP '
     0     0 DROP       tcp  --  *      *       0.0.0.0/0 
0.0.0.0/0           tcp flags:0x3F/0x3F
     0     0 LOG        tcp  --  *      *       0.0.0.0/0 
0.0.0.0/0           tcp flags:0x3F/0x29 LOG flags 0 level 4 prefix 
`fp=bad_tcp_packets:4 a=DROP '
     0     0 DROP       tcp  --  *      *       0.0.0.0/0 
0.0.0.0/0           tcp flags:0x3F/0x29
     0     0 LOG        tcp  --  *      *       0.0.0.0/0 
0.0.0.0/0           tcp flags:0x3F/0x37 LOG flags 0 level 4 prefix 
`fp=bad_tcp_packets:5 a=DROP '
     0     0 DROP       tcp  --  *      *       0.0.0.0/0 
0.0.0.0/0           tcp flags:0x3F/0x37
     0     0 LOG        tcp  --  *      *       0.0.0.0/0 
0.0.0.0/0           tcp flags:0x06/0x06 LOG flags 0 level 4 prefix 
`fp=bad_tcp_packets:6 a=DROP '
     0     0 DROP       tcp  --  *      *       0.0.0.0/0 
0.0.0.0/0           tcp flags:0x06/0x06
     0     0 LOG        tcp  --  *      *       0.0.0.0/0 
0.0.0.0/0           tcp flags:0x03/0x03 LOG flags 0 level 4 prefix 
`fp=bad_tcp_packets:7 a=DROP '
     0     0 DROP       tcp  --  *      *       0.0.0.0/0 
0.0.0.0/0           tcp flags:0x03/0x03
   316 21488 RETURN     tcp  --  *      *       0.0.0.0/0 
0.0.0.0/0


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2010-04-27 17:03 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-04-25 17:55 [BUG] 2.6.33.2-rt13 and iptables FC
2010-04-27  8:13 ` Thomas Gleixner
2010-04-27 17:03   ` FC

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).