linux-kernel - Re: [PATCH 0/2][RFC] Potential fix for leapsecond caused futex issue (v2)

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <4FF1F193.3000707@us.ibm.com>
Date:	Mon, 02 Jul 2012 12:08:03 -0700
From:	John Stultz <johnstul@...ibm.com>
To:	Dave Jones <davej@...hat.com>,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	Prarit Bhargava <prarit@...hat.com>, stable@...r.kernel.org,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH 0/2][RFC] Potential fix for leapsecond caused futex issue
 (v2)

On 07/02/2012 11:51 AM, Dave Jones wrote:
> On Sun, Jul 01, 2012 at 09:12:59PM -0700, John Stultz wrote:
>   > On 07/01/2012 11:29 AM, John Stultz wrote:
>   > > TODOs:
>   > > * Chase down the futex/hrtimer interaction to see if this could
>   > > be triggered in any other way.
>   > > * Get Tglx's input/ack
>   > > * Generate a backport for pre-v3.4 kernels
>   > So while still waiting for feedback on the clock_was_set() change, I
>   > went ahead and generated backports for most of the stable kernels on
>   > kernel.org.
>   >
>   > Clearly these shouldn't go anywhere until the fix is upstream, but since
>   > I assume there's a number of distro developers who are likely under
>   > pressure to have a fix soon, I wanted to make them available so no one
>   > is duplicating work.
>   >
>   > You can find them here:
>   > http://git.linaro.org/gitweb?p=people/jstultz/linux.git;a=summary
>   >
>   > I did boot and test each of those kernels with my leaptest-timer.c test
>   > successfully.
>
> I'm curious how the test that I did with the kernel patch,
> or Richard Cochran's userspace test program didn't trigger this bug
> when we tested last week.

It likely did trigger the issue.

> any ideas what we missed ?

In order to observe this issue, you need to notice that CLOCK_REALTIME 
timers are firing one second early.  The issue does not affect 
CLOCK_MONOTONIC timers.  Its only most visible with applications that 
make sub-second CLOCK_REALTIME timeouts in a loop (most reported cases 
connected with futexs). So if such an application wasn't running, it 
would be easy to overlook.

thanks
-john

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/