ASSERT ip_conntrack_core.c:622 &ip_conntrack_lock not readlocked

ASSERT ip_conntrack_core.c:622 &ip_conntrack_lock not readlocked

[Ron Arts]

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

I get this error on kernel 2.4.21pre4 when I boot. RH 2.4.18 didn't have this problem:

Mar 12 14:05:52 n000007 kernel: ASSERT ip_conntrack_core.c:622 &ip_conntrack_lock not readlocked
Mar 12 14:05:52 n000007 last message repeated 2 times
Mar 12 14:05:52 n000007 kernel: unable to load module ip_conntrack_ftp
Mar 12 14:05:52 n000007 kernel: ip_nat_ftp: error registering helper for port 121
Mar 12 14:05:52 n000007 kernel: ASSERT ip_conntrack_core.c:622 &ip_conntrack_lock not readlocked
Mar 12 14:05:52 n000007 nbs-iptables: /lib/modules/2.4.21-0NBS/kernel/net/ipv4/netfilter/ip_nat_ftp.o:
Mar 12 14:05:52 n000007 nbs-iptables: Hint: insmod errors can be caused by incorrect module parameters, including invalid IO
  or IRQ parameters
Mar 12 14:05:52 n000007 nbs-iptables: init_module: Device or resource busy
Mar 12 14:05:52 n000007 nbs-iptables: /lib/modules/2.4.21-0NBS/kernel/net/ipv4/netfilter/ip_nat_ftp.o: insmod /lib/modules/2
.4.21-0NBS/kernel/net/ipv4/netfilter/ip_nat_ftp.o failed
Mar 12 14:05:52 n000007 nbs-iptables: /lib/modules/2.4.21-0NBS/kernel/net/ipv4/netfilter/ip_nat_ftp.o: insmod ip_nat_ftp fai
led

Is this a known problem?

Ron Arts


-- 
Netland Internet Services
bedrijfsmatige internetoplossingen

http://www.netland.nl   Kruislaan 419              1098 VA Amsterdam
info: 020-5628282       servicedesk: 020-5628280   fax: 020-5628281

Unrecoverable Error #666: Armegeddon in 30..29..28..27..

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3291 bytes --]

ASSERT ip_conntrack_core.c:622 &ip_conntrack_lock not readlocked

[Ron Arts]

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

I get this error on kernel 2.4.21pre4 when I boot. RH 2.4.18 didn't have this problem:

Mar 12 14:05:52 n000007 kernel: ASSERT ip_conntrack_core.c:622 &ip_conntrack_lock not readlocked
Mar 12 14:05:52 n000007 last message repeated 2 times
Mar 12 14:05:52 n000007 kernel: unable to load module ip_conntrack_ftp
Mar 12 14:05:52 n000007 kernel: ip_nat_ftp: error registering helper for port 121
Mar 12 14:05:52 n000007 kernel: ASSERT ip_conntrack_core.c:622 &ip_conntrack_lock not readlocked
Mar 12 14:05:52 n000007 nbs-iptables: /lib/modules/2.4.21-0NBS/kernel/net/ipv4/netfilter/ip_nat_ftp.o:
Mar 12 14:05:52 n000007 nbs-iptables: Hint: insmod errors can be caused by incorrect module parameters, including invalid IO
  or IRQ parameters
Mar 12 14:05:52 n000007 nbs-iptables: init_module: Device or resource busy
Mar 12 14:05:52 n000007 nbs-iptables: /lib/modules/2.4.21-0NBS/kernel/net/ipv4/netfilter/ip_nat_ftp.o: insmod /lib/modules/2
.4.21-0NBS/kernel/net/ipv4/netfilter/ip_nat_ftp.o failed
Mar 12 14:05:52 n000007 nbs-iptables: /lib/modules/2.4.21-0NBS/kernel/net/ipv4/netfilter/ip_nat_ftp.o: insmod ip_nat_ftp fai
led

Is this a known problem?

Ron Arts

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3465 bytes --]

Re: ASSERT ip_conntrack_core.c:622 &ip_conntrack_lock not readlocked

[Martin Josefsson]

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

On Wed, 2003-03-12 at 21:34, Ron Arts wrote:
> I get this error on kernel 2.4.21pre4 when I boot. RH 2.4.18 didn't have this problem:
> 
> Mar 12 14:05:52 n000007 kernel: ASSERT ip_conntrack_core.c:622 &ip_conntrack_lock not readlocked
>
> Is this a known problem?

It looks like it's the NAT code that's abusing the locking a bit.
It calls a function in conntrack without taking the correct lock first.

I've attached a small patch that should fix it.
The patch is completely untested, not even testcompiled...
YMMV :)

It would be great if you could try it out and report back if it fixes
the problem or not. This patch will only fix the ASSERT warnings. Not
the actual error that ip_conntrack_ftp couldn't be loaded.

I havn't checked the RH 2.4.18 kernel but I doubt they have netfilter
compiled with debugging like you have. It's the debugging code that
prints out the ASSERT warnings.

Oh now I noticed one more thing. I believe you are trying something like
this:

modprobe ip_nat_ftp ports=121

This will fail unless ip_conntrack_ftp was loaded the same way:

modprobe ip_conntrack_ftp ports=121

The autoloading will not supply the correct arguments to
ip_conntrack_ftp when it tries to autoload it which happens when you
load ip_nat_ftp without having ip_conntrack_ftp loaded.

The error-message could be improved to say what exactly went wrong...
I've attached a small patch for that as well...
(not tested or testcompiled either)

Time to continue trying to get rid of the flu... good night.

-- 
/Martin

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

[-- Attachment #2: ip_ct_find_helper.patch --]
[-- Type: text/plain, Size: 1317 bytes --]

--- linux-2.4.20/net/ipv4/netfilter/ip_conntrack_core.c.orig	2003-03-12 23:08:49.000000000 +0100
+++ linux-2.4.20/net/ipv4/netfilter/ip_conntrack_core.c	2003-03-12 23:12:05.000000000 +0100
@@ -617,13 +617,24 @@
 	return ip_ct_tuple_mask_cmp(rtuple, &i->tuple, &i->mask);
 }
 
-struct ip_conntrack_helper *ip_ct_find_helper(const struct ip_conntrack_tuple *tuple)
+struct ip_conntrack_helper *__ip_ct_find_helper(const struct ip_conntrack_tuple *tuple)
 {
 	return LIST_FIND(&helpers, helper_cmp,
 			 struct ip_conntrack_helper *,
 			 tuple);
 }
 
+struct ip_conntrack_helper *ip_ct_find_helper(const struct ip_conntrack_tuple *tuple)
+{
+	struct ip_conntrack_helper *helper;
+	
+	READ_LOCK(&ip_conntrack_lock);
+	helper = __ip_ct_find_helper(tuple);
+	READ_UNLOCK(&ip_conntrack_lock);
+
+	return helper;
+}
+
 /* Allocate a new conntrack: we return -ENOMEM if classification
    failed due to stress.  Otherwise it really is unclassifiable. */
 static struct ip_conntrack_tuple_hash *
@@ -702,7 +713,7 @@
 
 	/* Look up the conntrack helper for master connections only */
 	if (!expected)
-		conntrack->helper = ip_ct_find_helper(&repl_tuple);
+		conntrack->helper = __ip_ct_find_helper(&repl_tuple);
 
 	/* If the expectation is dying, then this is a looser. */
 	if (expected

[-- Attachment #3: ip_nat_helper-request_module.patch --]
[-- Type: text/plain, Size: 776 bytes --]

--- linux-2.4.20/net/ipv4/netfilter/ip_nat_helper.c.orig	2003-03-12 23:33:56.000000000 +0100
+++ linux-2.4.20/net/ipv4/netfilter/ip_nat_helper.c	2003-03-12 23:40:29.000000000 +0100
@@ -501,12 +501,14 @@
 			tmp += 6;
 			sprintf(name, "ip_conntrack%s", tmp);
 #ifdef CONFIG_KMOD
-			if (!request_module(name)
-			    && (ct_helper = ip_ct_find_helper(&me->tuple))
+			if (request_module(name)) {
+				printk("unable to load module %s\n", name);
+				return -EBUSY;
+			} else if ((ct_helper = ip_ct_find_helper(&me->tuple))
 			    && ct_helper->me) {
 				__MOD_INC_USE_COUNT(ct_helper->me);
 			} else {
-				printk("unable to load module %s\n", name);
+				printk("unable to find sought helper from module %s\n", name);
 				return -EBUSY;
 			}
 #else