Bug#660425: [squeeze domU] alignment check trap on high network load

[Jonathan Nieder <jrnieder@gmail.com>]

Hi,

Radu Spineanu wrote:

> Since a couple of days ago on high loads a domU is constantly 
> rebooting itself after a kernel panic.

Sorry to have missed this before.  What are the xen and dom0 versions?
How reproducible is this?  (100%? 50%?)  Can you say a little more
about the nature of the load?  Does "dmesg" or "xm dmesg" from the
dom0 say anything interesting when this happens?  Is the backtrace
always the same?  Which CPU?  (A copy of /proc/cpuinfo would be
interesting.)  Any other relevant observations?

> [ 58.806593] alignment check: 0000 [#1] SMP
> [ 58.806610] last sysfs file: /sys/module/x_tables/initstate
[...]
> [ 58.806673] RIP: e030:[<ffffffff81270c0b>] [<ffffffff81270c0b>] eth_type_trans+0x3d/0xae
[...]
> [ 58.807061] Code: 87 d8 00 00 00 2b 87 d0 00 00 00 be 0e 00 00 00 89 87 c4 00 00 00 e8 68 48 fe ff 8b 8b c4 00 00 00 48 03 8b d0 00 00 00 f6 01 01 <48> 8b 11 74 20 48 33 95 40 02 00 00 8a 43 7d 48 c1 e2 10 75 08

This trace is of net/ethernet/eth.c, after "eth = eth_hdr(skb);":

  10: 89 87 c4 00 00 00       mov    %eax,0xc4(%rdi)
  16: e8 68 48 fe ff          callq  0xfffffffffffe4883
  1b: 8b 8b c4 00 00 00       mov    0xc4(%rbx),%ecx
  21: 48 03 8b d0 00 00 00    add    0xd0(%rbx),%rcx
  28: f6 01 01                testb  $0x1,(%rcx)
  2b:*      48 8b 11                mov    (%rcx),%rdx     <-- trapping instruction
  2e: 74 20                   je     0x50

The "if" is

	if (unlikely(is_multicast_ether_addr(eth->h_dest))) {

Linux loads the six bytes of eth->h_dest and two (irrelevant) bytes of
the next field because it will be comparing to another address soon.

The address of *eth (in %rcx) is as well aligned as we could hope
(16-bit aligned).

> [ 58.806690] RSP: e02b:ffff8801cd07f988 EFLAGS: 00050246
> [ 58.806695] RAX: ffff8801fb29ecfc RBX: ffff8801fbb44ce8 RCX: ffff8801fb29ecee

The guest is not supposed to be able to set EFLAGS.AC, so this feels
like a silicon or supervisor bug.

Compare:

 http://thread.gmane.org/gmane.comp.emulators.xen.devel/100514
 https://bugzilla.kernel.org/show_bug.cgi?id=25182
 http://thread.gmane.org/gmane.comp.emulators.xen.devel/80223

Hope that helps,
Jonathan