This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

To: Patrick McHardy <kaber@xxxxxxxxx>
Subject: Re: [Xen-devel] Re: Panic in ipt_do_table with
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Tue, 23 May 2006 22:15:58 +0100
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Netfilter Development Mailinglist <netfilter-devel@xxxxxxxxxxxxxxxxxxx>, James Morris <jmorris@xxxxxxxxx>, Matt Ayres <matta@xxxxxxxxxxxx>, Linux Kernel Mailing List <linux-kernel@xxxxxxxxxxxxxxx>
Delivery-date: Tue, 23 May 2006 14:21:15 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <4471CE19.5070802@xxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <4468BE70.7030802@xxxxxxxxxxxx> <4468D613.20309@xxxxxxxxx> <44691669.4080903@xxxxxxxxxxxx> <Pine.LNX.4.64.0605152331140.10964@xxxxxxx> <4469D84F.8080709@xxxxxxxxxxxx> <Pine.LNX.4.64.0605161127030.16379@xxxxxxx> <446D0A0D.5090608@xxxxxxxxxxxx> <Pine.LNX.4.64.0605182002330.6528@xxxxxxx> <446D0E6D.2080600@xxxxxxxxxxxx> <446D151D.6030307@xxxxxxxxxxxx> <4470A6CD.5010501@xxxxxxxxx> <4471CB54.401@xxxxxxxxxxxx> <4471CE19.5070802@xxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx

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

Xen-devel mailing list