Re: conntrackd [ERROR] commit: Invalid argument

[Pablo Neira Ayuso <pablo@netfilter.org>]

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

Rainer Sabelka wrote:
> On Wednesday 11 June 2008 18:26, Pablo Neira Ayuso wrote:
>> Rainer Sabelka wrote:
>>> On Wednesday 11 June 2008 15:25, Pablo Neira Ayuso wrote:
>>>> Are your scripts committing the entries twice (ie. invoking conntrackd
>>>> -c several times)?
>>> In my case - yes I did.
>>>
>>>> The only way to reproduce this that I have found is
>>>> to double insert an existing conntrack with some NAT handling. In the
>>>> upcoming 2.6.26 you'll get a EBUSY instead of EINVAL which sounds more
>>>> reasonable.
>>>>
>>>> Anyhow, does the patch attached fix this behaviour? The idea behind it
>>>> is to check if there is a conntrack present in kernel, if so, just
>>>> update the attributes of the conntrack object that are changeable to
>>>> avoid the error. Would you mind testing it?
>>> Thanks for the patch!
>>> Now I see no more "commit: Invalid argument" in the logs. Instead I get
>>> something like this, which looks much fiendlier:
>>>
>>> Jun 11 15:36:48 fw1b conntrack-tools[13273]: committing external cache
>>> Jun 11 15:36:48 fw1b conntrack-tools[13273]: Committed 69 new entries
>>> Jun 11 15:36:48 fw1b conntrack-tools[13273]: 53 entries ignored, already
>>> exist
>>                                                              ^^^
>> I'll also fix the message (those entries are not ignored but updated).
>> Then I'll commit the patch asap.
>>
>>> But in rare cases I can see "commit-create: Cannot allocate memory".
>>> I also noticed this a few times before applying this patch. Is this
>>> something I should worry about?
>> Yes, very strange. ctnetlink is hitting ENOMEM, ie. it cannot create the
>> conntrack because there's no memory available. As for now ctnetlink is
>> allocating conntracks via nf_conntrack_alloc() which uses GFP_ATOMIC.
>> I'll send you a patch to relax this to check if that is the problem,
>> otherwise I think that the error is bogus.
>>
>>> Jun 11 15:40:07 fw1b conntrack-tools[13383]: committing external cache
>>> Jun 11 15:40:07 fw1b conntrack-tools[13383]: commit-create: Cannot
>>> allocate memory
>>> Jun 11 15:40:07 fw1b conntrack-tools[13383]: Committed 33 new entries
>>> Jun 11 15:40:07 fw1b conntrack-tools[13383]: 25 entries ignored, already
>>> exist Jun 11 15:40:07 fw1b conntrack-tools[13383]: 1 entries can't be
>>> committed
>> What it is really annoying is the fact that you hit error with that less
>> entries. I cannot reproduce that in my testbed with ~20000 entries. Are
>> you using some kind of embedded device? Architecture?
> 
> This is a vitual machine (i686) which 128 MByte of memory running under VMware 
> server 1.0.4.

Would you try this patch?

-- 
"Los honestos son inadaptados sociales" -- Les Luthiers

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

[PATCH] add allocation flag to nf_conntrack_alloc

ctnetlink does not need to allocate the conntrack entries with GFP_ATOMIC
as its code is executed in user context.

Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>

Index: net-2.6/include/net/netfilter/nf_conntrack.h
===================================================================
--- net-2.6.orig/include/net/netfilter/nf_conntrack.h	2008-06-12 14:43:41.000000000 +0200
+++ net-2.6/include/net/netfilter/nf_conntrack.h	2008-06-12 14:43:59.000000000 +0200
@@ -239,7 +239,8 @@
 extern void nf_conntrack_free(struct nf_conn *ct);
 extern struct nf_conn *
 nf_conntrack_alloc(const struct nf_conntrack_tuple *orig,
-		   const struct nf_conntrack_tuple *repl);
+		   const struct nf_conntrack_tuple *repl,
+		   gfp_t allocation);
 
 /* It's confirmed if it is, or has been in the hash table. */
 static inline int nf_ct_is_confirmed(struct nf_conn *ct)
Index: net-2.6/net/netfilter/nf_conntrack_core.c
===================================================================
--- net-2.6.orig/net/netfilter/nf_conntrack_core.c	2008-06-12 14:42:05.000000000 +0200
+++ net-2.6/net/netfilter/nf_conntrack_core.c	2008-06-12 14:45:31.000000000 +0200
@@ -466,7 +466,8 @@
 }
 
 struct nf_conn *nf_conntrack_alloc(const struct nf_conntrack_tuple *orig,
-				   const struct nf_conntrack_tuple *repl)
+				   const struct nf_conntrack_tuple *repl,
+				   gfp_t allocation)
 {
 	struct nf_conn *ct = NULL;
 
@@ -491,7 +492,7 @@
 		}
 	}
 
-	ct = kmem_cache_zalloc(nf_conntrack_cachep, GFP_ATOMIC);
+	ct = kmem_cache_zalloc(nf_conntrack_cachep, allocation);
 	if (ct == NULL) {
 		pr_debug("nf_conntrack_alloc: Can't alloc conntrack.\n");
 		atomic_dec(&nf_conntrack_count);
@@ -543,7 +544,7 @@
 		return NULL;
 	}
 
-	ct = nf_conntrack_alloc(tuple, &repl_tuple);
+	ct = nf_conntrack_alloc(tuple, &repl_tuple, GFP_ATOMIC);
 	if (ct == NULL || IS_ERR(ct)) {
 		pr_debug("Can't allocate conntrack.\n");
 		return (struct nf_conntrack_tuple_hash *)ct;
Index: net-2.6/net/netfilter/nf_conntrack_netlink.c
===================================================================
--- net-2.6.orig/net/netfilter/nf_conntrack_netlink.c	2008-06-12 14:45:42.000000000 +0200
+++ net-2.6/net/netfilter/nf_conntrack_netlink.c	2008-06-12 14:45:50.000000000 +0200
@@ -1130,7 +1130,7 @@
 	struct nf_conn_help *help;
 	struct nf_conntrack_helper *helper;
 
-	ct = nf_conntrack_alloc(otuple, rtuple);
+	ct = nf_conntrack_alloc(otuple, rtuple, GFP_KERNEL);
 	if (ct == NULL || IS_ERR(ct))
 		return -ENOMEM;