(pre-upstream) Potential fix for leapsecond caused futex issue
On Thu, Jul 05, 2012 at 10:19:34AM -0600, Tim Gardner wrote:
> On 07/05/2012 10:08 AM, Brad Figg wrote:
> > BugLink: http://bugs.launchpad.net/bugs/1020285
> > These patches are not yet in Linus' tree. Given that there will not be
> > an additional leap-second added for some time to come, it may be better
> > to just wait for these patches to reach Linus' tree.
> > John Stultz <email@example.com> has put together a 3 patch set to
> > address the leapsecond bug that was encountered this past weekend by
> > some sites.
> > This set has had some testing by a few people. This patch set in in
> > the process of being reviewed upstream on lkml. I have been running
> > a Quantal kernel with these patches applied. I am able to detect the
> > issue with an unpatched kernel. I ran the leap-second test app and
> > stress on a server system for 24+ hours without detecting the leap-second
> > issue. The patchset has also received an ack by an upstream tester
> > that had found issues with previous versions of this patcheset.
> > The following mailing list thread covers this patch set and the discussions
> > around them:
> > https://lkml.org/lkml/2012/7/4/78
> > John Stultz (3):
> > hrtimer: Fix clock_was_set so it is safe to call from irq context
> > time: Fix leapsecond triggered hrtimer/futex load spike issue
> > hrtimer: Update hrtimer base offsets each hrtimer_interrupt
> > include/linux/hrtimer.h | 3 +++
> > kernel/hrtimer.c | 31 +++++++++++++++++++++++++++----
> > kernel/time/timekeeping.c | 38 ++++++++++++++++++++++++++++++++++++++
> > 3 files changed, 68 insertions(+), 4 deletions(-)
> When accepted upstream we should definitely backport them to the
> affected LTS kernels since leap seconds happen approximately twice per year.
So far it goes back to Hardy, the test case posted upstream triggered
the issue on an Hardy install here.