From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754822AbbFLJcw (ORCPT ); Fri, 12 Jun 2015 05:32:52 -0400 Received: from terminus.zytor.com ([198.137.202.10]:34496 "EHLO terminus.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750931AbbFLJcr (ORCPT ); Fri, 12 Jun 2015 05:32:47 -0400 Date: Fri, 12 Jun 2015 02:32:31 -0700 From: tip-bot for John Stultz Message-ID: Cc: prarit@redhat.com, jack@suse.cz, john.stultz@linaro.org, richardcochran@gmail.com, hpa@zytor.com, bristot@redhat.com, linux-kernel@vger.kernel.org, mingo@kernel.org, jbohac@suse.cz, tglx@linutronix.de Reply-To: hpa@zytor.com, richardcochran@gmail.com, jack@suse.cz, john.stultz@linaro.org, prarit@redhat.com, tglx@linutronix.de, jbohac@suse.cz, mingo@kernel.org, linux-kernel@vger.kernel.org, bristot@redhat.com In-Reply-To: <1434063297-28657-5-git-send-email-john.stultz@linaro.org> References: <1434063297-28657-5-git-send-email-john.stultz@linaro.org> To: linux-tip-commits@vger.kernel.org Subject: [tip:timers/core] ntp: Do leapsecond adjustment in adjtimex read path Git-Commit-ID: 96efdcf2d080687e041b0353c604b708546689fd X-Mailer: tip-git-log-daemon Robot-ID: Robot-Unsubscribe: Contact to get blacklisted from these emails MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Commit-ID: 96efdcf2d080687e041b0353c604b708546689fd Gitweb: http://git.kernel.org/tip/96efdcf2d080687e041b0353c604b708546689fd Author: John Stultz AuthorDate: Thu, 11 Jun 2015 15:54:56 -0700 Committer: Thomas Gleixner CommitDate: Fri, 12 Jun 2015 11:15:49 +0200 ntp: Do leapsecond adjustment in adjtimex read path Since the leapsecond is applied at tick-time, this means there is a small window of time at the start of a leap-second where we cross into the next second before applying the leap. This patch modified adjtimex so that the leap-second is applied on the second edge. Providing more correct leapsecond behavior. This does make it so that adjtimex()'s returned time values can be inconsistent with time values read from gettimeofday() or clock_gettime(CLOCK_REALTIME,...) for a brief period of one tick at the leapsecond. However, those other interfaces do not provide the TIME_OOP time_state return that adjtimex() provides, which allows the leapsecond to be properly represented. They instead only see a time discontinuity, and cannot tell the first 23:59:59 from the repeated 23:59:59 leap second. This seems like a reasonable tradeoff given clock_gettime() / gettimeofday() cannot properly represent a leapsecond, and users likely care more about performance, while folks who are using adjtimex() more likely care about leap-second correctness. Signed-off-by: John Stultz Cc: Prarit Bhargava Cc: Daniel Bristot de Oliveira Cc: Richard Cochran Cc: Jan Kara Cc: Jiri Bohac Cc: Ingo Molnar Link: http://lkml.kernel.org/r/1434063297-28657-5-git-send-email-john.stultz@linaro.org Signed-off-by: Thomas Gleixner --- kernel/time/ntp.c | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/kernel/time/ntp.c b/kernel/time/ntp.c index 033743e..fb4d98c 100644 --- a/kernel/time/ntp.c +++ b/kernel/time/ntp.c @@ -740,6 +740,24 @@ int __do_adjtimex(struct timex *txc, struct timespec64 *ts, s32 *time_tai) if (!(time_status & STA_NANO)) txc->time.tv_usec /= NSEC_PER_USEC; + /* Handle leapsec adjustments */ + if (unlikely(ts->tv_sec >= ntp_next_leap_sec)) { + if ((time_state == TIME_INS) && (time_status & STA_INS)) { + result = TIME_OOP; + txc->tai++; + txc->time.tv_sec--; + } + if ((time_state == TIME_DEL) && (time_status & STA_DEL)) { + result = TIME_WAIT; + txc->tai--; + txc->time.tv_sec++; + } + if ((time_state == TIME_OOP) && + (ts->tv_sec == ntp_next_leap_sec)) { + result = TIME_WAIT; + } + } + return result; }