Please review arch/x86/kernel/pvclock.c to fix Docker/Mono crashes in new Kernels
Hi Paolo,
the crashes occure on bare-metal (3.13.0-49-generic) and Docker is inside of VMWare vCenter (4.2.0-35-generic). On 3.19.0-25-generic with some highload (200 client requests simultaneously) in Docker inside of VMWare vCenter it doesn't crash.
--
Олег Хальзов
SDE
Vestbery
17.05.2016, 14:06, "Paolo Bonzini" <[email protected]>:
Quoted 35 lines · Linus Torvalds
Quoted 8 lines · Andy Lutomirski
Quoted 3 lines
All of those fixes were intended to fix incorrect times being reported, not segfaults. Weird.
I'm assuming it's "time going backwards". I can easily see that causing segfaults.
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1450584 says the crashes occurs "more frequently on a vbox vm with multiple CPUs configured". If vbox tells the VM to use the vdso when it shouldn't (because the TSC is not stable on the host), bad things could happen.
However, based on the Xamarin bug comments and
http://lists.ximian.com/pipermail/mono-devel-list/2015-August/043181.html,
it looks like vbox after all doesn't use pvclock and the trigger seems to be https://github.com/torvalds/linux/commit/c70e1b475f37:With
__always_inlineonvread_pvclock, mono crashed. With noinline onvread_pvclock, mono doesn't crash. Weirdest part is that the pvclock isn't even used during my tests.Oleg, what is your environment exactly? You mentioned Docker, but are you also virtualizing and if so what is your hypervisor?
Taloth, do you know if it can it be reproduced under Xen or KVM or bare-metal? I'd trust them more than VirtualBox regarding timekeeping. I saw Amazon Linux mentioned in the mono mailing list archives which would point to Xen. Xen doesn't use the pvclock vdso code either, though.
Thanks,
Paolo