lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Tue, 24 Jul 2012 03:37:43 +0100
From:	Ben Hutchings <ben@...adent.org.uk>
To:	John Stultz <johnstul@...ibm.com>
Cc:	Christoph Biedl <linux-kernel.bfrz@...chmal.in-ulm.de>,
	stable@...r.kernel.org, Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 00/11] 3.2-stable: Fix for leapsecond caused
 hrtimer/futex issue

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.

Download attachment "signature.asc" of type "application/pgp-signature" (829 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ