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

John Stultz
2012-07-02T19:08:46Z

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