Re: BUG: 2.6.25-rc1: iptables postrouting setup causes oops

[Haavard Skinnemoen <hskinnemoen@atmel.com>]

On Wed, 13 Feb 2008 00:48:29 -0800
Andrew Morton <akpm@linux-foundation.org> wrote:

> On Tue, 12 Feb 2008 22:46:01 +1100 Ben Nizette <bn@niasdigital.com> wrote:
> 
> > 
> > On an AVR32, root over NFS, config attached, running (from a startup
> > script):
> > 
> > iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
> > 
> > Results in (dmesg extract including a bit of context for good measure):
> > -------------8<----------------
> > VFS: Mounted root (nfs filesystem).
> > Freeing init memory: 72K (90000000 - 90012000)
> > eth0: no IPv6 routers present
> > warning: `dnsmasq' uses 32-bit capabilities (legacy support in use)

Hmm. What does that mean? What size do capabilities normally have?

> > ip_tables: (C) 2000-2006 Netfilter Core Team
> > nf_conntrack version 0.5.0 (1024 buckets, 4096 max)
> > Unable to handle kernel paging request at virtual address d76a7138
> > ptbr = 91d3b000 pgd = 0000e5f3 pte = 00014370

Hmm. It actually found something in the pte? Looks like a swap
entry...but that doesn't make sense at that virtual address. Userspace
is below 0x80000000.

> > Oops: Kernel access of bad area, sig: 11 [#1]
> > FRAME_POINTER chip: 0x01f:0x1e82 rev 2
> > Modules linked in: nf_conntrack_ipv4(+) nf_conntrack ip_tables
> > PC is at kmem_cache_alloc+0x2c/0x54
> > LR is at nf_conntrack_l4proto_register+0x34/0x9c [nf_conntrack]
> 
> I take it that the above means that the crash is in kmem_cache_alloc()?

That's correct.

> If so, the bug could be almost anywhere - in slab, or in some random piece
> of code which scribbles on slab's data structures.

Yes, it looks like memory corruption, especially since the page table
appears to be corrupted as well. But I'll have a look and see if the
code that dumps the pte is doing something bogus...

> > Perfectly repeatable.
> 
> If my theory is correct, changing pretty much anything in the kernel config
> might just make it go away.  But still, it would be most valuable if you
> could try running a bisection search, as described in
> http://www.kernel.org/doc/local/git-quick.html, thanks.

Yes, that would be very valuable.

Haavard