lkml.org 
[lkml]   [2012]   [Jul]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH 00/11] 3.2-stable: Fix for leapsecond caused hrtimer/futex issue
From
Date
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.
[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2012-07-24 05:21    [W:0.075 / U:1.748 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site