[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <557AF2FD.2070606@redhat.com>
Date: Fri, 12 Jun 2015 10:55:57 -0400
From: Prarit Bhargava <prarit@...hat.com>
To: Dave Jones <davej@...emonkey.org.uk>,
John Stultz <john.stultz@...aro.org>,
linux-kernel@...r.kernel.org,
Daniel Bristot de Oliveira <bristot@...hat.com>,
Richard Cochran <richardcochran@...il.com>,
Jan Kara <jack@...e.cz>, Jiri Bohac <jbohac@...e.cz>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
Shuah Khan <shuahkh@....samsung.com>
Subject: Re: [PATCH 0/5 v2] Fixes for leapsecond expiring early ABS_TIME CLOCK_REALTIME
timers
On 06/12/2015 10:52 AM, Dave Jones wrote:
> On Thu, Jun 11, 2015 at 03:54:52PM -0700, John Stultz wrote:
> > So this is a second round at trying to address the issue, trying
> > to integrate feedback from Ingo and Thomas, trying to simplify
> > what I can. I've also split out the changes so each can be
> > more easily reviewed. Its still not tiny, but its simpler.
> >
> > This series is against tip/timers/core, and the first patch isn't
> > strictly related but is a fix that is needed in tip/timers/core.
> >
> > As Prarit reported here:
> > https://lkml.org/lkml/2015/5/27/458
> >
> > Since the leapsecond is applied at timer tick time, and not
> > the actual second edge, ABS_TIME CLOCK_REALTIME timers set for
> > right after the leapsecond could fire a second early, since
> > some timers may be expired before we trigger the timekeeping
> > timer, which then applies the leapsecond.
> >
> > Thus this patch series tries to address this issue, including
> > extending the leap-a-day test to catch this problem, as well
> > as other relevant fixups I found while working on the code.
> >
> > This series has only had limited testing, so I wanted to send
> > it out for initial review and comment. Folks can grab this tree
> > via git for testing here:
> > https://git.linaro.org/people/john.stultz/linux.git dev/early-leap-timer
>
> Any idea how far back this reaches ? Ie, which longterm stable releases
> might be affected by this ?
>
Likely occurs in any kernel after NOHZ was introduced.
> (It really creeps me out that we're still changing this code so close
> to the next leap second event).
>
davej, I'm not taking this into RHEL because of the obvious stability concerns.
I'm also very much against taking this into linux-stable for now until we can
get some testing done on it.
FWIW I'd rather live with the devil we know ...
I'm going to be testing (heavily) over the weekend.
P.
> Dave
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists