linux-kernel - Re: [PATCH 00/11] 3.2-stable: Fix for leapsecond caused hrtimer/futex issue

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <50050FD9.3070403@us.ibm.com>
Date:	Tue, 17 Jul 2012 00:10:17 -0700
From:	John Stultz <johnstul@...ibm.com>
To:	John Stultz <johnstul@...ibm.com>
CC:	stable@...r.kernel.org, Prarit Bhargava <prarit@...hat.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 00/11] 3.2-stable: Fix for leapsecond caused hrtimer/futex
 issue

On 07/17/2012 12:05 AM, John Stultz wrote:
> 1) Deadlock leapsecond issue that a few reports described.
>
> I spent some time over the weekend trying to find a way to reproduce
> the hard-hang issue some folks were reporting after the leapsecond.
> Initially I didn't think the 6b43ae8a619d17 leap-second hrimter livelock
> patch needed to be backported since, I assumed it required the ntp_lock
> split for it to be triggered, but looking again I found that the same
> issue could occur prior to splitting out the ntp_lock. So I've backported
> that fix (and its follow-on fixups) as well as created a test case
> to reproduce the hard-hang deadlock.

Attached is the test case I used to reproduce and test the solution to 
the hard-hang deadlock.

WARNING: THIS TEST WILL LIKELY HARD LOCK YOUR BOX IN IRQ CONTEXT!
YOU MAY LOSE DATA! RUN AT YOUR OWN RISK!

thanks
-john


View attachment "leapcrash.c" of type "text/x-csrc" (1929 bytes)