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
[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@xxxxxxxxxxxxx>
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;
