Messages in this thread |  | | | From | Keir Fraser <> | | Subject | Re: [Xen-devel] Re: Panic in ipt_do_table with 2.6.16.13-xen | | Date | Tue, 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/
|  |