2.4.20pre8aa2 failed assertions in ip_{conntrack,nat}_core.c

Another forgotten forward to this list.

Hi all !

[1.] 2.4.20pre8aa2 failed assertions in ip_{conntrack,nat}_core.c

[2.] Full description of the problem/report:
I'm running 2.4.20pre8aa2 with all the firewalling stuff enabled on a Pentium 75 and get occasionally
---- snip (lines broken to keep it readable) ----

Oct 10 20:00:04 fw kernel: ASSERT ip_conntrack_core.c:97
                             &ip_conntrack_lock readlocked 
Oct 10 20:00:04 fw kernel: ASSERT ip_conntrack_core.c:1067
                             &ip_conntrack_lock not readlocked 
Oct 10 20:00:04 fw kernel: ASSERT: ip_nat_core.c:841
                             &ip_conntrack_lock not readlocked 
Oct 10 20:00:04 fw kernel: ASSERT ip_conntrack_core.c:97
                             &ip_conntrack_lock readlocked 
Oct 10 20:00:04 fw kernel: ASSERT: ip_nat_core.c:841
                             &ip_conntrack_lock not readlocked 

---- snip ----
Otherwise everything is working fine.

[3.] Keywords (i.e., modules, networking, kernel):
networking, firewalling, connection-tracking

[4.] Kernel version (from /proc/version):
Linux version 2.4.20-pre8aa2 (...) (gcc version 2.95.4 20010319 (prerelease/franzo/20011204)) #2 Wed Oct 9 20:43:34 CEST 2002

[6.] A small shell script or example program which triggers the
problem (if possible)
Simply http'ing or ftp'ing trigger it occasionally. The symptom is that a particular (TCP-)connection "freezes".

[7.] Environment
[7.1.] Software (add the output of the ver_linux script here)

Gnu C                  2.95.4
Gnu make               3.79.1
util-linux             2.11b
mount                  2.10r
modutils               2.4.18
e2fsprogs              1.25
Linux C Library        2.1.3
Dynamic linker (ldd)   2.1.3
Procps                 2.0.6
Net-tools              1.54
Console-tools          0.3.3
Sh-utils               2.0

[7.2.] Processor information (from /proc/cpuinfo):
processor : 0
vendor_id : GenuineIntel
cpu family : 5
model : 2
model name : Pentium 75 - 200
stepping : 4
cpu MHz : 75.021
fdiv_bug : no
hlt_bug : no
f00f_bug : yes
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr mce cx8
bogomips : 149.50

[7.3.] Module information (from /proc/modules):
No modules enabled.

[7.4.] Loaded driver and hardware information (/proc/ioports, /proc/iomem) 10#cat /proc/ioports
0000-001f : dma1
0020-003f : pic1
0040-005f : timer
0060-006f : keyboard
0080-008f : dma page reg
00a0-00bf : pic2
00c0-00df : dma2
00f0-00ff : fpu
01f0-01f7 : ide0
0300-031f : eth1
03c0-03df : vga+
03f6-03f6 : ide0
0cf8-0cff : PCI conf1
e400-e47f : 3Com Corporation 3c900B-TPO [Etherlink XL TPO]
e400-e47f : 00:09.0
e800-e80f : Intel Corp. 82371FB PIIX IDE [Triton I]
e800-e807 : ide0
e808-e80f : ide1
11#cat /proc/iomem
00000000-0009ffff : System RAM
000a0000-000bffff : Video RAM area
000c0000-000c7fff : Video ROM
000f0000-000fffff : System ROM
00100000-05ffffff : System RAM
00100000-002116b5 : Kernel code
002116b6-00258d57 : Kernel data
10000000-13ffffff : S3 Inc. 86c968 [Vision 968 VRAM] rev 0 e7000000-e700007f : 3Com Corporation 3c900B-TPO [Etherlink XL TPO] ffff0000-ffffffff : reserved

[7.5.] PCI information ('lspci -vvv' as root)
Omitted since it is far more than 80 chars wide and IMHO not interesting in this case. Can actually send it if someone wishes.

[7.6.] SCSI information (from /proc/scsi/scsi)
No SCSI hardware.

[7.7.] Other information that might be relevant to the problem
(please look in /proc and include all information that you think to be relevant):
Actually don't know really in this case. Is there any interesting?

Bernd

Bernd Petrovitsch                              Email : [email protected]
g.a.m.s gmbh                                  Fax : +43 1 205255-900
Prinz-Eugen-Straße 8                    A-1040 Vienna/Austria/Europe
                     LUGA : http://www.luga.at


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

I've attached a small patch that fixes the ip_conntrack_core.c:97 and ip_nat_core.c:841 messages, These two messages aren't bugs in the locking, it's just the lock-debugging that can't handle "recursive" read-locks on the same lock and cpu correctly and thus reports an error even though everything is fine.
(the patch is made against 2.4.20-pre8-ac2 but it should apply.)

ASSERT ip_conntrack_core.c:1067 &ip_conntrack_lock not readlocked this might be a real locking-bug but it's only used in conntrack-handlers so unless you have two expectations happening at the same time on diffrent cpu's there's no problem. I'll look into it.

hmm, shouldn't happen. Can you describe it in more detail?

/Martin

Never argue with an idiot. They drag you down to their level, then beat
you with experience.

diff -x '*.orig' -urN linux-2.4.20-pre8-ac3.orig/include/linux/netfilter_ipv4/ip_conntrack_core.h linux-2.4.20-pre8-ac3/include/linux/netfilter_ipv4/ip_conntrack_core.h
@@ -17,7 +17,7 @@
 struct ip_conntrack_protocol;
 extern struct ip_conntrack_protocol *ip_ct_find_proto(u_int8_t protocol);
 /* Like above, but you already have conntrack read lock. */
-extern struct ip_conntrack_protocol *__find_proto(u_int8_t protocol);
+extern struct ip_conntrack_protocol *__ip_ct_find_proto(u_int8_t protocol);
 extern struct list_head protocol_list;
 
 /* Returns conntrack if it dealt with ICMP, and filled in skb->nfct */

diff -x '*.orig' -urN linux-2.4.20-pre8-ac3.orig/net/ipv4/netfilter/ip_conntrack_core.c linux-2.4.20-pre8-ac3/net/ipv4/netfilter/ip_conntrack_core.c
@@ -74,7 +74,7 @@
 	return protocol == curr->proto;
 }
 
-struct ip_conntrack_protocol *__find_proto(u_int8_t protocol)
+struct ip_conntrack_protocol *__ip_ct_find_proto(u_int8_t protocol)
 {
 	struct ip_conntrack_protocol *p;
 

@@ -92,7 +92,7 @@
 	struct ip_conntrack_protocol *p;
 
 	READ_LOCK(&ip_conntrack_lock);
-	p = __find_proto(protocol);
+	p = __ip_ct_find_proto(protocol);
 	READ_UNLOCK(&ip_conntrack_lock);
 	return p;
 }

diff -x '*.orig' -urN linux-2.4.20-pre8-ac3.orig/net/ipv4/netfilter/ip_conntrack_standalone.c linux-2.4.20-pre8-ac3/net/ipv4/netfilter/ip_conntrack_standalone.c
@@ -71,7 +71,7 @@
 	len += sprintf(buffer + len, "use=%u proto=%u ",
 		      atomic_read(&expect->use), expect->tuple.dst.protonum);
 	len += print_tuple(buffer + len, &expect->tuple,
-			   __find_proto(expect->tuple.dst.protonum));
+			   __ip_ct_find_proto(expect->tuple.dst.protonum));
 	len += sprintf(buffer + len, "\n");
 	return len;
 }

@@ -81,7 +81,7 @@
 {
 	unsigned int len;
 	struct ip_conntrack_protocol *proto
-		= __find_proto(conntrack->tuplehash[IP_CT_DIR_ORIGINAL]
+		= __ip_ct_find_proto(conntrack->tuplehash[IP_CT_DIR_ORIGINAL]
 			       .tuple.dst.protonum);
 
 	len = sprintf(buffer, "%-8s %u %lu ",

@@ -361,6 +361,7 @@
 EXPORT_SYMBOL(ip_ct_selective_cleanup);
 EXPORT_SYMBOL(ip_ct_refresh);
 EXPORT_SYMBOL(ip_ct_find_proto);
+EXPORT_SYMBOL(__ip_ct_find_proto);
 EXPORT_SYMBOL(ip_ct_find_helper);
 EXPORT_SYMBOL(ip_conntrack_expect_related);
 EXPORT_SYMBOL(ip_conntrack_change_expect);

diff -x '*.orig' -urN linux-2.4.20-pre8-ac3.orig/net/ipv4/netfilter/ip_nat_core.c linux-2.4.20-pre8-ac3/net/ipv4/netfilter/ip_nat_core.c
@@ -739,7 +739,7 @@
 	int ret = 1;
 
 	MUST_BE_READ_LOCKED(&ip_conntrack_lock);
-	proto = ip_ct_find_proto((*pskb)->nh.iph->protocol);
+	proto = __ip_ct_find_proto((*pskb)->nh.iph->protocol);
 	if (proto->exp_matches_pkt)
 		ret = proto->exp_matches_pkt(exp, pskb);
 

This explains why the box was actually usable.

It does. Compiled and boot4ed the patched kernel.

Thanks!

Not really, it just popped up a dozen times within 3 hours within 7 minutes (hmm, God knows what I was doing exactly at that time to trigger it).
And I actually realized it only because some <tab> completion in ncftp hang (of course it came out on the console but who is looking there all the time since that's not the primary PC). I'll see if it occurs again .....

Bernd

Bernd Petrovitsch                              Email : [email protected]
g.a.m.s gmbh                                  Fax : +43 1 205255-900
Prinz-Eugen-Straße 8                    A-1040 Vienna/Austria/Europe
                     LUGA : http://www.luga.at