lkml.org 
[lkml]   [2012]   [Jul]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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



\
 
 \ /
  Last update: 2012-07-02 21:41    [W:0.238 / U:0.096 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site