On Tue, 29 Apr 2008, Pekka Enberg wrote:

quoted text
> Well, it's obviously nf_conntrack_cachep but this is the second time I see the
> SLUB WARN_ON trigger but can't find anything wrong with the code. Christoph,
> if you look at nf_conntrack_cleanup() in net/netfilter/nf_conntrack_core.c:
> 
>  i_see_dead_people:
>         nf_conntrack_flush();
>         if (atomic_read(&nf_conntrack_count) != 0) {
>                 schedule();
>                 goto i_see_dead_people;
>         }

And we are sure that no additional items are allocatable after this?

quoted text
>         ct = kmem_cache_zalloc(nf_conntrack_cachep, GFP_ATOMIC);
> 
> So I don't see how we can call kmem_cache_destroy() with unfree'd objects in
> it... Can you take a look at this?

Nothing jumps out but then there are numerous components involved.

quoted text
> And oh, Peter, if you can trigger this with mainline, please do post the oops.
> I should give us better information what's happening.

The new diagnostics should give us a lot more data to go on. Make sure you 
run with "slub_debug" as a kernel parameter or SLUB_DEBUG_ON configured.

The dump will include the time and place when the remaining objects were 
allocated which should resolve this issue.

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html