3.9 / 3.10: Reliable host crashes

Jul 10 15:33:37 fsdevel7 kernel: [  507.995602] br0: port 3(tap2) entered disabled state
Jul 10 15:33:37 fsdevel7 kernel: [  508.043454] BUG: unable to handle kernel NULL pointer dereference at 0000000000000020
Jul 10 15:33:37 fsdevel7 kernel: [  508.043487] IP: [<ffffffff811825b9>] get_ksm_page+0x39/0x130

Jul 10 15:34:49 fsdevel7 kernel: [  580.274709] RIP: 0010:[<ffffffff8116d694>]  [<ffffffff8116d694>] anon_vma_clone+0x94/0x1a0
Jul 10 15:34:49 fsdevel7 kernel: [  580.274710] RSP: 0018:ffff880406495cf0  EFLAGS: 00010286

Jul 10 15:34:49 fsdevel7 kernel: [  580.274721] Call Trace:
Jul 10 15:34:49 fsdevel7 kernel: [  580.274724]  [<ffffffff8116d868>] anon_vma_fork+0x38/0x130
Jul 10 15:34:49 fsdevel7 kernel: [  580.274728]  [<ffffffff8105770f>] dup_mmap+0x1bf/0x420

qemu-system-x86_64                                                      \
        -m 8192                                                         \
        -machine type=pc,accel=kvm,kernel_irqchip=on                    \
        -netdev type=tap,script=${kvm_ifup},downscript=${kvm_ifdown},ifname=$iface,vhost=on,id=guest0   \
        -device virtio-net-pci,netdev=guest0,mac=52:54:00:12:34:11      \
        -boot c                                                         \

        -drive file=${FILE},if=${DISKIF},cache=unsafe                   \
        -drive file=${META},if=${DISKIF},cache=writeback                \
        -drive file=${STORAGE},if=${DISKIF},cache=writeback             \
        -enable-kvm                                                     \
        -vga vmware                                                     \
        -cpu host                                                       \
        -smp 4                                                          \
        "$@"

Hi all,

I found a way to reliably crash my host system:

1) Boot guest VM with init=/bin/bash

2) In guest VM: echo b >/proc/sysrq-trigger

3) Try to reboot the guest -> crashes the host during kernel initialization

When I checked the logs I first thought it would be a KSM issue:

Quoted 3 lines

Jul 10 15:33:37 fsdevel7 kernel: [  507.995602] br0: port 3(tap2) entered disabled state
Jul 10 15:33:37 fsdevel7 kernel: [  508.043454] BUG: unable to handle kernel NULL pointer dereference at 0000000000000020
Jul 10 15:33:37 fsdevel7 kernel: [  508.043487] IP: [<ffffffff811825b9>] get_ksm_page+0x39/0x130

and

Quoted 6 lines

Jul 10 15:34:49 fsdevel7 kernel: [  580.274709] RIP: 0010:[<ffffffff8116d694>]  [<ffffffff8116d694>] anon_vma_clone+0x94/0x1a0
Jul 10 15:34:49 fsdevel7 kernel: [  580.274710] RSP: 0018:ffff880406495cf0  EFLAGS: 00010286

Jul 10 15:34:49 fsdevel7 kernel: [  580.274721] Call Trace:
Jul 10 15:34:49 fsdevel7 kernel: [  580.274724]  [<ffffffff8116d868>] anon_vma_fork+0x38/0x130
Jul 10 15:34:49 fsdevel7 kernel: [  580.274728]  [<ffffffff8105770f>] dup_mmap+0x1bf/0x420

But then I simply disabled KSM in rc.local
(echo 0 > /sys/kernel/mm/ksm/run) before starting the VMs. Now the system still crashes, but now without any logs message. At least sysrq-b still works, but I don' see any
"SysRq : Emergency Sync" messages in log files. So log messages are not written properly anymore. Unfortunately I don't have a serial console on my desktop system.

I don't have the time now, but the next step is probably to get a crash-dump and to see if that has something useful. And I'm also going to run the VM from a tty without X, maybe it prints something to the console.
Anything else you might want? Or already any idea? Crashes do not happen with 3.8-ubuntu, but very reliably with 3.9.9 or 3.10.1 (host).

Here's my kvm command line:

Quoted 6 lines

qemu-system-x86_64                                                      \
       -m 8192                                                         \
       -machine type=pc,accel=kvm,kernel_irqchip=on                    \
       -netdev type=tap,script=${kvm_ifup},downscript=${kvm_ifdown},ifname=$iface,vhost=on,id=guest0   \
       -device virtio-net-pci,netdev=guest0,mac=52:54:00:12:34:11      \
       -boot c                                                         \

Quoted 8 lines

       -drive file=${FILE},if=${DISKIF},cache=unsafe                   \
       -drive file=${META},if=${DISKIF},cache=writeback                \
       -drive file=${STORAGE},if=${DISKIF},cache=writeback             \
       -enable-kvm                                                     \
       -vga vmware                                                     \
       -cpu host                                                       \
       -smp 4                                                          \
       "$@"

Thanks,
Bernd

--
To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Quoted 4 lines · Bernd Schubert

Hi all,

I found a way to reliably crash my host system:

Quoted 6 lines

1) Boot guest VM with init=/bin/bash

2) In guest VM: echo b >/proc/sysrq-trigger

3) Try to reboot the guest -> crashes the host during kernel initialization

What 3 means? 2 already reboots it.

Quoted 1 line

What is your host cpu? cat /proc/cpuinfo.

processor : 3
vendor_id : GenuineIntel
cpu family : 6
model : 42
model name : Intel(R) Core(TM) i5-2500 CPU @ 3.30GHz
stepping : 7
microcode : 0x28
cpu MHz : 3292.517
cache size : 6144 KB
physical id : 0
siblings : 4
core id : 3
cpu cores : 4
apicid : 6
initial apicid : 6
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid
bogomips : 6585.03
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:

Quoted 9 lines · Gleb Natapov

Quoted 8 lines · Bernd Schubert

Hi all,

I found a way to reliably crash my host system:

1) Boot guest VM with init=/bin/bash

2) In guest VM: echo b >/proc/sysrq-trigger

Quoted 3 lines

Quoted 2 lines

3) Try to reboot the guest -> crashes the host during kernel initialization

What 3 means? 2 already reboots it.

Sorry, not a good wording. The guest reboots, goes through grub, starts the kernel and the host then crashes during early initialization of the guest kernel.

Quoted 13 lines · Gleb Natapov

Quoted 12 lines · Bernd Schubert

Quoted 11 lines · Gleb Natapov

Quoted 10 lines · Bernd Schubert

Hi all,

I found a way to reliably crash my host system:

1) Boot guest VM with init=/bin/bash

2) In guest VM: echo b >/proc/sysrq-trigger

3) Try to reboot the guest -> crashes the host during kernel initialization

Quoted 7 lines

Quoted 5 lines

Quoted 1 line

What 3 means? 2 already reboots it.

Sorry, not a good wording. The guest reboots, goes through grub, starts the kernel and the host then crashes during early initialization of the guest kernel.

And if you boot it without init= first and just reboot it with "reboot" does the same happens?

I currently need the host and the VMs, so I can't try that right now.

Quoted 1 line

Quoted 2 lines

Can your attach your .config here? Also can you compile KSM out and retry?

The host config ist attached.

I probably will only manage to test that on Friday afternoon, I guess only the host KSM is important?