On Thursday 12 June 2008 17:01:04 Pablo Neira Ayuso wrote:
> >> 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?
Pablo,
I tried to debug this a bit and added some printk()s in the
ctnetlink_create_conntrack() function to find out where the ENOMEM is coming
from:
So, now I see that nf_conntrack_alloc() is not returning this error, but it is
coming from a couple of lines below in the same function:
helper = nf_ct_helper_find_get(rtuple);
if (helper) {
help = nf_ct_helper_ext_add(ct, GFP_KERNEL);
if (help == NULL) {
nf_ct_helper_put(helper);
err = -ENOMEM;
goto err;
}
There, nf_ct_helper_ext_add() returns NULL, which causes ENOMEM to be
returned.
I didn't debug this further because I'm rather lost in the code. But maybe
this gives you some hint what's wrong.
-Rainer
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
