[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] 100% reliable oops on Xen 4.1.3 (initially reported on 4.0.1)

  • To: xen-devel@xxxxxxxxxxxxx
  • From: Peter Moody <pmoody@xxxxxxxxxx>
  • Date: Mon, 28 Jan 2013 11:17:21 -0800
  • Delivery-date: Mon, 28 Jan 2013 20:13:40 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xen.org>

TL;DR, the domU crash I reported over the summer on Xen 4.0.1 can be
reproduced on 4.1.3 and on more processor families and with out the
special memory/cpu configurations I previously reported.

Longer version:
apropos of this thread [1] from last summer, I've managed to test for
this bug on a more recent version of Xen and I can confirm that it
exists in at least 4.1.3. Also, based on the release notes for 4.0.1
[2] (the original version of Xen where I encountered this issue), I
reproduced the bug on an AMD Athlon processor in case the interrupts
issue mentioned had an effect.

The patch I posted to the audit list didn't actually fix the problem.

Steps I used to reproduce:
1) installed Xen from ubuntu packages and boot into Xen enabled system.
2) installed ubuntu 12.10 domU using 20G flat file as disk (the
previous system used drbd).
3) installed auditd and inserted any syscall rule (audit on chmod's
for example).
4) compiled the attached sample program as a 32 bit binary.
5) ran it (works as a normal user).

The result is an immediate crash (if KILLDIR doesn't exist or isn't
writable, you just get a segfault).

Interestingly, it also seems to leave dom0 in a funky state where dom0
is unable to reboot (I think it has to do with the disk file not being
unmounted). I can only recover from this cleanly by running xm destroy
on the crashed domain.

This is my xen configuration for this particular domain:

memory = "1024"
disk = [ 'file:/home/pmoody/virt/xen/xen-bug/disk1.img,xvda,w', ]
vif = [ 'bridge=xenbr0', ]
on_reboot = "restart"
on_crash = "restart"

(the number of vcpus doesn't appear to be important). From my recent
testing, it seems like it should be very easy for someone else to
reproduce this issue.

So, does anyone have any idea of what might be going on?


[1] http://lists.xen.org/archives/html/xen-devel/2012-08/msg01052.html
[2] http://wiki.xen.org/wiki/Xen_4.0_Release_Notes#Known_issues

[ Peter Moody | Security Engineer | Google ]

Attachment: crasher.c
Description: Text Data

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.