3.9 / 3.10: Reliable host crashes

3.9 / 3.10: Reliable host crashes

[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


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

> 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


> 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:

> 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                                                          \
>         "$@"



Thanks,
Bernd

Re: 3.9 / 3.10: Reliable host crashes

[Gleb Natapov]

On Wed, Jul 10, 2013 at 04:16:46PM +0200, Bernd Schubert wrote:
> 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
> 
What 3 means? 2 already reboots it.

> 
> When I checked the logs I first thought it would be a KSM issue:
> 
> >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
> 
> 
> >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).
> 
What is your host cpu? cat /proc/cpuinfo.

> Here's my kvm command line:
> 
> >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                                                          \
> >        "$@"
> 
> 
> 
> Thanks,
> Bernd
> 
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
			Gleb.

Re: 3.9 / 3.10: Reliable host crashes

[Bernd Schubert]

On 07/10/2013 06:02 PM, Gleb Natapov wrote:
> On Wed, Jul 10, 2013 at 04:16:46PM +0200, Bernd Schubert wrote:
>> 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
>>
> 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.


[...]

>>
> 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:

Re: 3.9 / 3.10: Reliable host crashes

[Gleb Natapov]

On Wed, Jul 10, 2013 at 06:06:27PM +0200, Bernd Schubert wrote:
> On 07/10/2013 06:02 PM, Gleb Natapov wrote:
> >On Wed, Jul 10, 2013 at 04:16:46PM +0200, Bernd Schubert wrote:
> >>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
> >>
> >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?

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

--
			Gleb.

Re: 3.9 / 3.10: Reliable host crashes

[Gleb Natapov]

On Wed, Jul 10, 2013 at 06:23:26PM +0200, Bernd Schubert wrote:
> On 07/10/2013 06:16 PM, Gleb Natapov wrote:
> >On Wed, Jul 10, 2013 at 06:06:27PM +0200, Bernd Schubert wrote:
> >>On 07/10/2013 06:02 PM, Gleb Natapov wrote:
> >>>On Wed, Jul 10, 2013 at 04:16:46PM +0200, Bernd Schubert wrote:
> >>>>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
> >>>>
> >>>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.
> 
> >
> >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?
> 
Yes.

--
			Gleb.