Re: [PATCH 00/11] 3.2-stable: Fix for leapsecond causedhrtimer/futex issue
From: Ben Hutchings
Date: Mon Jul 23 2012 - 22:38:39 EST
On Mon, 2012-07-23 at 12:51 -0700, John Stultz wrote:
> On 07/19/2012 01:48 PM, Christoph Biedl wrote:
> > John Stultz wrote...
> >> Attached is the test case I used to reproduce and test the solution
> >> to the hard-hang deadlock.
> > I was wondering whether anybody managed to crash a virtualbox guest
> > using your program. No avail, using version 4.1.18 on the host and the
> > guest kernel running several 3.0.x (x < 38) kernels on both x32 and
> > x64, the guest utilies were stopped. Rather a fun fact I guess but I
> > wanted to let you know.
> I've been able to crash a kvm guest with an unpatched kernel with my
> test. The issue requires that the adding of the hrtimer causes the
> clockevent to be reprogrammed. This usually happens if there's no timers
> that expire sooner then the leapsecond timer. So if there are drivers
> that set frequent timers, or set timers right before the leapsecond, it
> may be difficult to trigger this issue.
> Lowering HZ or adding more vcpus might help if you really want to be
> able to trigger the issue.
Your test program also made Linux 3.2.23 (or it may have been .21)
lock-up for me in a KVM guest, while 3.2.24-rc1 seemed immune.
If more than one person is responsible for a bug, no one is at fault.
Description: This is a digitally signed message part