Re: [Xen-devel] Re: Panic in ipt_do_table with 2.6.16.13-xen

[Matt Ayres]

Keir Fraser wrote:
> On 22 May 2006, at 15:43, Patrick McHardy wrote:
>
> > Maybe this helps: there is not too much the Xen code could be doing
> > wrong here. If I read your crash correctly it happend in the FORWARD
> > chain, which could mean that the outgoing device (probably the Xen
> > virtual network driver) has some bugs, but iptables really only cares
> > about the names at this point, which practically can't be bogus.
> > The only other thing I can imagine is that something is wrong with
> > the per-CPU copy of the ruleset, i.e. either smp_processor_id is
> > returning garbage or for_each_possible_cpu misses a CPU during
> > initialization. I have no idea if Xen really does touch this code,
> > but other than that I don't really see what it could break.
>
> Having looked at disassembly, the fault happens when accessing 
> e->ip.invflags in ip_packet_match() inlined inside ipt_do_table().
>
>  e = private->entries[smp_processor_id()] + 
> private->hook_entry[NF_IP_FORWARD]
>
> smp_processor_id() should be 0 (since the oops appears to occur on cpu0) 
> and presumably all the ipt_entry structures are static once set up. 
> Since this crash happens on a common path in ipt_do_table(), and since 
> it happens only after the system has been up a while (I believe?), it 
> rather looks as though something has either corrupted a pointer or 
> unmapped memory from under iptables' feet.

As the concerned user, what does this mean to me?  It will only affect 
SMP systems?  It is a bug in Xen or netfilter?

I'd just like to understand what is going on.

Thanks,
Matt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/