From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: <4FF1F193.3000707@us.ibm.com> Date: Mon, 02 Jul 2012 12:08:03 -0700 From: John Stultz MIME-Version: 1.0 To: Dave Jones , Linux Kernel , Prarit Bhargava , stable@vger.kernel.org, Thomas Gleixner Subject: Re: [PATCH 0/2][RFC] Potential fix for leapsecond caused futex issue (v2) References: <1341167401-31342-1-git-send-email-johnstul@us.ibm.com> <4FF11FCB.4030207@us.ibm.com> <20120702185103.GA32257@redhat.com> In-Reply-To: <20120702185103.GA32257@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: 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