Messages in this thread | | | Date | Mon, 02 Jul 2012 12:08:03 -0700 | From | John Stultz <> | 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
| |