Re: Re: Panic in ipt_do_table with 2.6.16.13-xen

[Matt Ayres <matta@tektonic.net>]

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