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
| ||
|
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/
Powered by blists - more mailing lists