[tip:timers/core] ntp: Do leapsecond adjustment in adjtimex read path
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.stu...@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;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:timers/core] ntp: Do leapsecond adjustment in adjtimex read path
Commit-ID: 96efdcf2d080687e041b0353c604b708546689fd
Gitweb: http://git.kernel.org/tip/96efdcf2d080687e041b0353c604b708546689fd
Author: John Stultz john.stu...@linaro.org
AuthorDate: Thu, 11 Jun 2015 15:54:56 -0700
Committer: Thomas Gleixner t...@linutronix.de
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 john.stu...@linaro.org
Cc: Prarit Bhargava pra...@redhat.com
Cc: Daniel Bristot de Oliveira bris...@redhat.com
Cc: Richard Cochran richardcoch...@gmail.com
Cc: Jan Kara j...@suse.cz
Cc: Jiri Bohac jbo...@suse.cz
Cc: Ingo Molnar mi...@kernel.org
Link:
http://lkml.kernel.org/r/1434063297-28657-5-git-send-email-john.stu...@linaro.org
Signed-off-by: Thomas Gleixner t...@linutronix.de
---
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;
}
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
