Re: [PATCH 00/11] 3.2-stable: Fix for leapsecond causedhrtimer/futex issue

[Ben Hutchings]

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.

Ben.

-- 
Ben Hutchings
If more than one person is responsible for a bug, no one is at fault.

Attachment: signature.asc
Description: This is a digitally signed message part