lkml.org 
[lkml]   [2006]   [May]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
FromKeir Fraser <>
SubjectRe: [Xen-devel] Re: Panic in ipt_do_table with 2.6.16.13-xen
DateTue, 23 May 2006 22:15:58 +0100

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.
-- Keir

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

\
 
 \ /
  Last update: 2006-05-23 23:23    [from the cache]
©2003-2010