License cleanup: add SPDX GPL-2.0 license identifier to files with no license
Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.
By default all files without license information are under the default
license of the kernel, which is GPL version 2.
Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier. The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.
This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.
How this work was done:
Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
- file had no licensing information it it.
- file was a */uapi/* one with no licensing information in it,
- file was a */uapi/* one with existing licensing information,
Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.
The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne. Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.
The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed. Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.
Criteria used to select files for SPDX license identifier tagging was:
- Files considered eligible had to be source code files.
- Make and config files were included as candidates if they contained >5
lines of source
- File already had some variant of a license header in it (even if <5
lines).
All documentation files were explicitly excluded.
The following heuristics were used to determine which SPDX license
identifiers to apply.
- when both scanners couldn't find any license traces, file was
considered to have no license information in it, and the top level
COPYING file license applied.
For non */uapi/* files that summary was:
SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 11139
and resulted in the first patch in this series.
If that file was a */uapi/* path one, it was "GPL-2.0 WITH
Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was:
SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 WITH Linux-syscall-note 930
and resulted in the second patch in this series.
- if a file had some form of licensing information in it, and was one
of the */uapi/* ones, it was denoted with the Linux-syscall-note if
any GPL family license was found in the file or had no licensing in
it (per prior point). Results summary:
SPDX license identifier # files
---------------------------------------------------|------
GPL-2.0 WITH Linux-syscall-note 270
GPL-2.0+ WITH Linux-syscall-note 169
((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21
((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17
LGPL-2.1+ WITH Linux-syscall-note 15
GPL-1.0+ WITH Linux-syscall-note 14
((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5
LGPL-2.0+ WITH Linux-syscall-note 4
LGPL-2.1 WITH Linux-syscall-note 3
((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3
((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1
and that resulted in the third patch in this series.
- when the two scanners agreed on the detected license(s), that became
the concluded license(s).
- when there was disagreement between the two scanners (one detected a
license but the other didn't, or they both detected different
licenses) a manual inspection of the file occurred.
- In most cases a manual inspection of the information in the file
resulted in a clear resolution of the license that should apply (and
which scanner probably needed to revisit its heuristics).
- When it was not immediately clear, the license identifier was
confirmed with lawyers working with the Linux Foundation.
- If there was any question as to the appropriate license identifier,
the file was flagged for further research and to be revisited later
in time.
In total, over 70 hours of logged manual review was done on the
spreadsheet to determine the SPDX license identifiers to apply to the
source files by Kate, Philippe, Thomas and, in some cases, confirmation
by lawyers working with the Linux Foundation.
Kate also obtained a third independent scan of the 4.13 code base from
FOSSology, and compared selected files where the other two scanners
disagreed against that SPDX file, to see if there was new insights. The
Windriver scanner is based on an older version of FOSSology in part, so
they are related.
Thomas did random spot checks in about 500 files from the spreadsheets
for the uapi headers and agreed with SPDX license identifier in the
files he inspected. For the non-uapi files Thomas did random spot checks
in about 15000 files.
In initial set of patches against 4.14-rc6, 3 files were found to have
copy/paste license identifier errors, and have been fixed to reflect the
correct identifier.
Additionally Philippe spent 10 hours this week doing a detailed manual
inspection and review of the 12,461 patched files from the initial patch
version early this week with:
- a full scancode scan run, collecting the matched texts, detected
license ids and scores
- reviewing anything where there was a license detected (about 500+
files) to ensure that the applied SPDX license was correct
- reviewing anything where there was no detection but the patch license
was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
SPDX license was correct
This produced a worksheet with 20 files needing minor correction. This
worksheet was then exported into 3 different .csv files for the
different types of files to be modified.
These .csv files were then reviewed by Greg. Thomas wrote a script to
parse the csv files and add the proper SPDX tag to the file, in the
format that the file expected. This script was further refined by Greg
based on the output to detect more types of files automatically and to
distinguish between header and source .c files (which need different
comment types.) Finally Greg ran the script using the .csv files to
generate the patches.
Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org>
Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-11-01 17:07:57 +03:00
// SPDX-License-Identifier: GPL-2.0
2006-10-01 10:28:22 +04:00
/*
* NTP state machine interfaces and logic .
*
* This code was mainly moved from kernel / timer . c and kernel / time . c
* Please see those files for relevant copyright info and historical
* changelogs .
*/
2007-07-16 10:40:39 +04:00
# include <linux/capability.h>
2008-05-01 15:34:41 +04:00
# include <linux/clocksource.h>
2008-09-23 01:42:40 +04:00
# include <linux/workqueue.h>
2008-02-20 09:58:42 +03:00
# include <linux/hrtimer.h>
# include <linux/jiffies.h>
# include <linux/math64.h>
# include <linux/timex.h>
# include <linux/time.h>
# include <linux/mm.h>
2011-01-13 04:00:56 +03:00
# include <linux/module.h>
2012-12-18 01:30:53 +04:00
# include <linux/rtc.h>
2015-12-13 07:26:42 +03:00
# include <linux/math64.h>
2006-10-01 10:28:22 +04:00
2013-03-22 22:31:29 +04:00
# include "ntp_internal.h"
2015-12-13 07:24:19 +03:00
# include "timekeeping_internal.h"
2011-01-27 18:00:32 +03:00
2006-10-01 10:28:22 +04:00
/*
2008-02-20 09:58:42 +03:00
* NTP timekeeping variables :
2013-03-22 22:52:03 +04:00
*
* Note : All of the NTP state is protected by the timekeeping locks .
2006-10-01 10:28:22 +04:00
*/
2011-11-15 01:48:36 +04:00
2008-02-20 09:58:42 +03:00
/* USER_HZ period (usecs): */
unsigned long tick_usec = TICK_USEC ;
2012-07-27 22:48:10 +04:00
/* SHIFTED_HZ period (nsecs): */
2008-02-20 09:58:42 +03:00
unsigned long tick_nsec ;
2008-05-01 15:34:41 +04:00
2011-11-15 01:18:07 +04:00
static u64 tick_length ;
2008-02-20 09:58:42 +03:00
static u64 tick_length_base ;
2015-06-12 01:54:54 +03:00
# define SECS_PER_DAY 86400
2009-02-22 14:11:11 +03:00
# define MAX_TICKADJ 500LL /* usecs */
2008-02-20 09:58:42 +03:00
# define MAX_TICKADJ_SCALED \
2009-02-22 14:11:11 +03:00
( ( ( MAX_TICKADJ * NSEC_PER_USEC ) < < NTP_SCALE_SHIFT ) / NTP_INTERVAL_FREQ )
2006-10-01 10:28:22 +04:00
/*
* phase - lock loop variables
*/
2008-02-20 09:58:42 +03:00
/*
* clock synchronization status
*
* ( TIME_ERROR prevents overwriting the CMOS clock )
*/
static int time_state = TIME_OK ;
/* clock status bits: */
2011-11-15 01:06:21 +04:00
static int time_status = STA_UNSYNC ;
2008-02-20 09:58:42 +03:00
/* time adjustment (nsecs): */
static s64 time_offset ;
/* pll time constant: */
static long time_constant = 2 ;
/* maximum error (usecs): */
2010-01-29 02:02:41 +03:00
static long time_maxerror = NTP_PHASE_LIMIT ;
2008-02-20 09:58:42 +03:00
/* estimated error (usecs): */
2010-01-29 02:02:41 +03:00
static long time_esterror = NTP_PHASE_LIMIT ;
2008-02-20 09:58:42 +03:00
/* frequency offset (scaled nsecs/secs): */
static s64 time_freq ;
/* time at last adjustment (secs): */
2015-12-13 07:24:19 +03:00
static time64_t time_reftime ;
2008-02-20 09:58:42 +03:00
2010-03-19 06:19:27 +03:00
static long time_adjust ;
2008-02-20 09:58:42 +03:00
2009-02-22 18:03:37 +03:00
/* constant (boot-param configurable) NTP tick adjustment (upscaled) */
static s64 ntp_tick_adj ;
2008-02-20 09:58:42 +03:00
time: Prevent early expiry of hrtimers[CLOCK_REALTIME] at the leap second edge
Currently, leapsecond adjustments are done at tick time. As a result,
the leapsecond was applied at the first timer tick *after* the
leapsecond (~1-10ms late depending on HZ), rather then exactly on the
second edge.
This was in part historical from back when we were always tick based,
but correcting this since has been avoided since it adds extra
conditional checks in the gettime fastpath, which has performance
overhead.
However, it was recently pointed out that 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.
This isn't quite as bad as it sounds, since behaviorally it is similar
to what is possible w/ ntpd made leapsecond adjustments done w/o using
the kernel discipline. Where due to latencies, timers may fire just
prior to the settimeofday call. (Also, one should note that all
applications using CLOCK_REALTIME timers should always be careful,
since they are prone to quirks from settimeofday() disturbances.)
However, the purpose of having the kernel do the leap adjustment is to
avoid such latencies, so I think this is worth fixing.
So in order to properly keep those timers from firing a second early,
this patch modifies the ntp and timekeeping logic so that we keep
enough state so that the update_base_offsets_now accessor, which
provides the hrtimer core the current time, can check and apply the
leapsecond adjustment on the second edge. This prevents the hrtimer
core from expiring timers too early.
This patch does not modify any other time read path, so no additional
overhead is incurred. However, this also means that the leap-second
continues to be applied at tick time for all other read-paths.
Apologies to Richard Cochran, who pushed for similar changes years
ago, which I resisted due to the concerns about the performance
overhead.
While I suspect this isn't extremely critical, folks who care about
strict leap-second correctness will likely want to watch
this. Potentially a -stable candidate eventually.
Originally-suggested-by: Richard Cochran <richardcochran@gmail.com>
Reported-by: Daniel Bristot de Oliveira <bristot@redhat.com>
Reported-by: Prarit Bhargava <prarit@redhat.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Cc: Richard Cochran <richardcochran@gmail.com>
Cc: Jan Kara <jack@suse.cz>
Cc: Jiri Bohac <jbohac@suse.cz>
Cc: Shuah Khan <shuahkh@osg.samsung.com>
Cc: Ingo Molnar <mingo@kernel.org>
Link: http://lkml.kernel.org/r/1434063297-28657-4-git-send-email-john.stultz@linaro.org
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2015-06-12 01:54:55 +03:00
/* second value of the next pending leapsecond, or TIME64_MAX if no leap */
static time64_t ntp_next_leap_sec = TIME64_MAX ;
2011-01-13 04:00:56 +03:00
# ifdef CONFIG_NTP_PPS
/*
* The following variables are used when a pulse - per - second ( PPS ) signal
* is available . They establish the engineering parameters of the clock
* discipline loop when controlled by the PPS signal .
*/
# define PPS_VALID 10 /* PPS signal watchdog max (s) */
# define PPS_POPCORN 4 /* popcorn spike threshold (shift) */
# define PPS_INTMIN 2 /* min freq interval (s) (shift) */
# define PPS_INTMAX 8 /* max freq interval (s) (shift) */
# define PPS_INTCOUNT 4 / * number of consecutive good intervals to
increase pps_shift or consecutive bad
intervals to decrease it */
# define PPS_MAXWANDER 100000 /* max PPS freq wander (ns/s) */
static int pps_valid ; /* signal watchdog counter */
static long pps_tf [ 3 ] ; /* phase median filter */
static long pps_jitter ; /* current jitter (ns) */
2015-09-28 23:21:28 +03:00
static struct timespec64 pps_fbase ; /* beginning of the last freq interval */
2011-01-13 04:00:56 +03:00
static int pps_shift ; /* current interval duration (s) (shift) */
static int pps_intcnt ; /* interval counter */
static s64 pps_freq ; /* frequency offset (scaled ns/s) */
static long pps_stabil ; /* current stability (scaled ns/s) */
/*
* PPS signal quality monitors
*/
static long pps_calcnt ; /* calibration intervals */
static long pps_jitcnt ; /* jitter limit exceeded */
static long pps_stbcnt ; /* stability limit exceeded */
static long pps_errcnt ; /* calibration errors */
/* PPS kernel consumer compensates the whole phase error immediately.
* Otherwise , reduce the offset by a fixed factor times the time constant .
*/
static inline s64 ntp_offset_chunk ( s64 offset )
{
if ( time_status & STA_PPSTIME & & time_status & STA_PPSSIGNAL )
return offset ;
else
return shift_right ( offset , SHIFT_PLL + time_constant ) ;
}
static inline void pps_reset_freq_interval ( void )
{
/* the PPS calibration interval may end
surprisingly early */
pps_shift = PPS_INTMIN ;
pps_intcnt = 0 ;
}
/**
* pps_clear - Clears the PPS state variables
*/
static inline void pps_clear ( void )
{
pps_reset_freq_interval ( ) ;
pps_tf [ 0 ] = 0 ;
pps_tf [ 1 ] = 0 ;
pps_tf [ 2 ] = 0 ;
pps_fbase . tv_sec = pps_fbase . tv_nsec = 0 ;
pps_freq = 0 ;
}
/* Decrease pps_valid to indicate that another second has passed since
* the last PPS signal . When it reaches 0 , indicate that PPS signal is
* missing .
*/
static inline void pps_dec_valid ( void )
{
if ( pps_valid > 0 )
pps_valid - - ;
else {
time_status & = ~ ( STA_PPSSIGNAL | STA_PPSJITTER |
STA_PPSWANDER | STA_PPSERROR ) ;
pps_clear ( ) ;
}
}
static inline void pps_set_freq ( s64 freq )
{
pps_freq = freq ;
}
static inline int is_error_status ( int status )
{
2014-05-12 17:35:48 +04:00
return ( status & ( STA_UNSYNC | STA_CLOCKERR ) )
2011-01-13 04:00:56 +03:00
/* PPS signal lost when either PPS time or
* PPS frequency synchronization requested
*/
2014-05-12 17:35:48 +04:00
| | ( ( status & ( STA_PPSFREQ | STA_PPSTIME ) )
& & ! ( status & STA_PPSSIGNAL ) )
2011-01-13 04:00:56 +03:00
/* PPS jitter exceeded when
* PPS time synchronization requested */
2014-05-12 17:35:48 +04:00
| | ( ( status & ( STA_PPSTIME | STA_PPSJITTER ) )
2011-01-13 04:00:56 +03:00
= = ( STA_PPSTIME | STA_PPSJITTER ) )
/* PPS wander exceeded or calibration error when
* PPS frequency synchronization requested
*/
2014-05-12 17:35:48 +04:00
| | ( ( status & STA_PPSFREQ )
& & ( status & ( STA_PPSWANDER | STA_PPSERROR ) ) ) ;
2011-01-13 04:00:56 +03:00
}
static inline void pps_fill_timex ( struct timex * txc )
{
txc - > ppsfreq = shift_right ( ( pps_freq > > PPM_SCALE_INV_SHIFT ) *
PPM_SCALE_INV , NTP_SCALE_SHIFT ) ;
txc - > jitter = pps_jitter ;
if ( ! ( time_status & STA_NANO ) )
txc - > jitter / = NSEC_PER_USEC ;
txc - > shift = pps_shift ;
txc - > stabil = pps_stabil ;
txc - > jitcnt = pps_jitcnt ;
txc - > calcnt = pps_calcnt ;
txc - > errcnt = pps_errcnt ;
txc - > stbcnt = pps_stbcnt ;
}
# else /* !CONFIG_NTP_PPS */
static inline s64 ntp_offset_chunk ( s64 offset )
{
return shift_right ( offset , SHIFT_PLL + time_constant ) ;
}
static inline void pps_reset_freq_interval ( void ) { }
static inline void pps_clear ( void ) { }
static inline void pps_dec_valid ( void ) { }
static inline void pps_set_freq ( s64 freq ) { }
static inline int is_error_status ( int status )
{
return status & ( STA_UNSYNC | STA_CLOCKERR ) ;
}
static inline void pps_fill_timex ( struct timex * txc )
{
/* PPS is not implemented, so these are zero */
txc - > ppsfreq = 0 ;
txc - > jitter = 0 ;
txc - > shift = 0 ;
txc - > stabil = 0 ;
txc - > jitcnt = 0 ;
txc - > calcnt = 0 ;
txc - > errcnt = 0 ;
txc - > stbcnt = 0 ;
}
# endif /* CONFIG_NTP_PPS */
2011-11-15 01:06:21 +04:00
/**
* ntp_synced - Returns 1 if the NTP status is not UNSYNC
*
*/
static inline int ntp_synced ( void )
{
return ! ( time_status & STA_UNSYNC ) ;
}
2008-02-20 09:58:42 +03:00
/*
* NTP methods :
*/
2006-10-01 10:28:22 +04:00
2009-02-22 14:42:59 +03:00
/*
* Update ( tick_length , tick_length_base , tick_nsec ) , based
* on ( tick_usec , ntp_tick_adj , time_freq ) :
*/
2006-10-01 10:28:29 +04:00
static void ntp_update_frequency ( void )
{
2009-02-22 14:42:59 +03:00
u64 second_length ;
2009-02-22 14:17:36 +03:00
u64 new_base ;
2009-02-22 14:42:59 +03:00
second_length = ( u64 ) ( tick_usec * NSEC_PER_USEC * USER_HZ )
< < NTP_SCALE_SHIFT ;
2009-02-22 18:03:37 +03:00
second_length + = ntp_tick_adj ;
2009-02-22 14:42:59 +03:00
second_length + = time_freq ;
2006-10-01 10:28:29 +04:00
2009-02-22 14:42:59 +03:00
tick_nsec = div_u64 ( second_length , HZ ) > > NTP_SCALE_SHIFT ;
2009-02-22 14:17:36 +03:00
new_base = div_u64 ( second_length , NTP_INTERVAL_FREQ ) ;
2009-02-19 03:02:22 +03:00
/*
* Don ' t wait for the next second_overflow , apply
2009-02-22 14:17:36 +03:00
* the change to the tick length immediately :
2009-02-19 03:02:22 +03:00
*/
2009-02-22 14:17:36 +03:00
tick_length + = new_base - tick_length_base ;
tick_length_base = new_base ;
2006-10-01 10:28:29 +04:00
}
2009-02-22 15:22:23 +03:00
static inline s64 ntp_update_offset_fll ( s64 offset64 , long secs )
2009-02-22 14:57:49 +03:00
{
time_status & = ~ STA_MODE ;
if ( secs < MINSEC )
2009-02-22 15:22:23 +03:00
return 0 ;
2009-02-22 14:57:49 +03:00
if ( ! ( time_status & STA_FLL ) & & ( secs < = MAXSEC ) )
2009-02-22 15:22:23 +03:00
return 0 ;
2009-02-22 14:57:49 +03:00
time_status | = STA_MODE ;
2012-03-15 20:36:14 +04:00
return div64_long ( offset64 < < ( NTP_SCALE_SHIFT - SHIFT_FLL ) , secs ) ;
2009-02-22 14:57:49 +03:00
}
2008-05-01 15:34:32 +04:00
static void ntp_update_offset ( long offset )
{
s64 freq_adj ;
2009-02-22 14:57:49 +03:00
s64 offset64 ;
long secs ;
2008-05-01 15:34:32 +04:00
if ( ! ( time_status & STA_PLL ) )
return ;
2015-12-03 23:46:48 +03:00
if ( ! ( time_status & STA_NANO ) ) {
/* Make sure the multiplication below won't overflow */
offset = clamp ( offset , - USEC_PER_SEC , USEC_PER_SEC ) ;
2008-05-01 15:34:36 +04:00
offset * = NSEC_PER_USEC ;
2015-12-03 23:46:48 +03:00
}
2008-05-01 15:34:32 +04:00
/*
* Scale the phase adjustment and
* clamp to the operating range .
*/
2015-12-03 23:46:48 +03:00
offset = clamp ( offset , - MAXPHASE , MAXPHASE ) ;
2008-05-01 15:34:32 +04:00
/*
* Select how the frequency is to be controlled
* and in which mode ( PLL or FLL ) .
*/
2015-12-13 07:24:19 +03:00
secs = ( long ) ( __ktime_get_real_seconds ( ) - time_reftime ) ;
2009-02-22 15:38:40 +03:00
if ( unlikely ( time_status & STA_FREQHOLD ) )
2009-02-22 15:29:09 +03:00
secs = 0 ;
2015-12-13 07:24:19 +03:00
time_reftime = __ktime_get_real_seconds ( ) ;
2008-05-01 15:34:32 +04:00
2009-02-22 14:57:49 +03:00
offset64 = offset ;
2010-09-07 18:43:46 +04:00
freq_adj = ntp_update_offset_fll ( offset64 , secs ) ;
2009-02-22 14:57:49 +03:00
2010-09-07 18:43:46 +04:00
/*
* Clamp update interval to reduce PLL gain with low
* sampling rate ( e . g . intermittent network connection )
* to avoid instability .
*/
if ( unlikely ( secs > 1 < < ( SHIFT_PLL + 1 + time_constant ) ) )
secs = 1 < < ( SHIFT_PLL + 1 + time_constant ) ;
freq_adj + = ( offset64 * secs ) < <
( NTP_SCALE_SHIFT - 2 * ( SHIFT_PLL + 2 + time_constant ) ) ;
2009-02-22 14:57:49 +03:00
freq_adj = min ( freq_adj + time_freq , MAXFREQ_SCALED ) ;
time_freq = max ( freq_adj , - MAXFREQ_SCALED ) ;
time_offset = div_s64 ( offset64 < < NTP_SCALE_SHIFT , NTP_INTERVAL_FREQ ) ;
2008-05-01 15:34:32 +04:00
}
2006-10-01 10:28:22 +04:00
/**
* ntp_clear - Clears the NTP state variables
*/
void ntp_clear ( void )
{
2008-02-20 09:58:42 +03:00
time_adjust = 0 ; /* stop active adjtime() */
time_status | = STA_UNSYNC ;
time_maxerror = NTP_PHASE_LIMIT ;
time_esterror = NTP_PHASE_LIMIT ;
2006-10-01 10:28:22 +04:00
ntp_update_frequency ( ) ;
2008-02-20 09:58:42 +03:00
tick_length = tick_length_base ;
time_offset = 0 ;
2011-01-13 04:00:56 +03:00
time: Prevent early expiry of hrtimers[CLOCK_REALTIME] at the leap second edge
Currently, leapsecond adjustments are done at tick time. As a result,
the leapsecond was applied at the first timer tick *after* the
leapsecond (~1-10ms late depending on HZ), rather then exactly on the
second edge.
This was in part historical from back when we were always tick based,
but correcting this since has been avoided since it adds extra
conditional checks in the gettime fastpath, which has performance
overhead.
However, it was recently pointed out that 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.
This isn't quite as bad as it sounds, since behaviorally it is similar
to what is possible w/ ntpd made leapsecond adjustments done w/o using
the kernel discipline. Where due to latencies, timers may fire just
prior to the settimeofday call. (Also, one should note that all
applications using CLOCK_REALTIME timers should always be careful,
since they are prone to quirks from settimeofday() disturbances.)
However, the purpose of having the kernel do the leap adjustment is to
avoid such latencies, so I think this is worth fixing.
So in order to properly keep those timers from firing a second early,
this patch modifies the ntp and timekeeping logic so that we keep
enough state so that the update_base_offsets_now accessor, which
provides the hrtimer core the current time, can check and apply the
leapsecond adjustment on the second edge. This prevents the hrtimer
core from expiring timers too early.
This patch does not modify any other time read path, so no additional
overhead is incurred. However, this also means that the leap-second
continues to be applied at tick time for all other read-paths.
Apologies to Richard Cochran, who pushed for similar changes years
ago, which I resisted due to the concerns about the performance
overhead.
While I suspect this isn't extremely critical, folks who care about
strict leap-second correctness will likely want to watch
this. Potentially a -stable candidate eventually.
Originally-suggested-by: Richard Cochran <richardcochran@gmail.com>
Reported-by: Daniel Bristot de Oliveira <bristot@redhat.com>
Reported-by: Prarit Bhargava <prarit@redhat.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Cc: Richard Cochran <richardcochran@gmail.com>
Cc: Jan Kara <jack@suse.cz>
Cc: Jiri Bohac <jbohac@suse.cz>
Cc: Shuah Khan <shuahkh@osg.samsung.com>
Cc: Ingo Molnar <mingo@kernel.org>
Link: http://lkml.kernel.org/r/1434063297-28657-4-git-send-email-john.stultz@linaro.org
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2015-06-12 01:54:55 +03:00
ntp_next_leap_sec = TIME64_MAX ;
2011-01-13 04:00:56 +03:00
/* Clear PPS state variables */
pps_clear ( ) ;
2006-10-01 10:28:22 +04:00
}
2011-11-15 01:18:07 +04:00
u64 ntp_tick_length ( void )
{
2013-03-22 22:52:03 +04:00
return tick_length ;
2011-11-15 01:18:07 +04:00
}
time: Prevent early expiry of hrtimers[CLOCK_REALTIME] at the leap second edge
Currently, leapsecond adjustments are done at tick time. As a result,
the leapsecond was applied at the first timer tick *after* the
leapsecond (~1-10ms late depending on HZ), rather then exactly on the
second edge.
This was in part historical from back when we were always tick based,
but correcting this since has been avoided since it adds extra
conditional checks in the gettime fastpath, which has performance
overhead.
However, it was recently pointed out that 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.
This isn't quite as bad as it sounds, since behaviorally it is similar
to what is possible w/ ntpd made leapsecond adjustments done w/o using
the kernel discipline. Where due to latencies, timers may fire just
prior to the settimeofday call. (Also, one should note that all
applications using CLOCK_REALTIME timers should always be careful,
since they are prone to quirks from settimeofday() disturbances.)
However, the purpose of having the kernel do the leap adjustment is to
avoid such latencies, so I think this is worth fixing.
So in order to properly keep those timers from firing a second early,
this patch modifies the ntp and timekeeping logic so that we keep
enough state so that the update_base_offsets_now accessor, which
provides the hrtimer core the current time, can check and apply the
leapsecond adjustment on the second edge. This prevents the hrtimer
core from expiring timers too early.
This patch does not modify any other time read path, so no additional
overhead is incurred. However, this also means that the leap-second
continues to be applied at tick time for all other read-paths.
Apologies to Richard Cochran, who pushed for similar changes years
ago, which I resisted due to the concerns about the performance
overhead.
While I suspect this isn't extremely critical, folks who care about
strict leap-second correctness will likely want to watch
this. Potentially a -stable candidate eventually.
Originally-suggested-by: Richard Cochran <richardcochran@gmail.com>
Reported-by: Daniel Bristot de Oliveira <bristot@redhat.com>
Reported-by: Prarit Bhargava <prarit@redhat.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Cc: Richard Cochran <richardcochran@gmail.com>
Cc: Jan Kara <jack@suse.cz>
Cc: Jiri Bohac <jbohac@suse.cz>
Cc: Shuah Khan <shuahkh@osg.samsung.com>
Cc: Ingo Molnar <mingo@kernel.org>
Link: http://lkml.kernel.org/r/1434063297-28657-4-git-send-email-john.stultz@linaro.org
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2015-06-12 01:54:55 +03:00
/**
* ntp_get_next_leap - Returns the next leapsecond in CLOCK_REALTIME ktime_t
*
* Provides the time of the next leapsecond against CLOCK_REALTIME in
* a ktime_t format . Returns KTIME_MAX if no leapsecond is pending .
*/
ktime_t ntp_get_next_leap ( void )
{
ktime_t ret ;
if ( ( time_state = = TIME_INS ) & & ( time_status & STA_INS ) )
return ktime_set ( ntp_next_leap_sec , 0 ) ;
2016-12-25 13:38:40 +03:00
ret = KTIME_MAX ;
time: Prevent early expiry of hrtimers[CLOCK_REALTIME] at the leap second edge
Currently, leapsecond adjustments are done at tick time. As a result,
the leapsecond was applied at the first timer tick *after* the
leapsecond (~1-10ms late depending on HZ), rather then exactly on the
second edge.
This was in part historical from back when we were always tick based,
but correcting this since has been avoided since it adds extra
conditional checks in the gettime fastpath, which has performance
overhead.
However, it was recently pointed out that 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.
This isn't quite as bad as it sounds, since behaviorally it is similar
to what is possible w/ ntpd made leapsecond adjustments done w/o using
the kernel discipline. Where due to latencies, timers may fire just
prior to the settimeofday call. (Also, one should note that all
applications using CLOCK_REALTIME timers should always be careful,
since they are prone to quirks from settimeofday() disturbances.)
However, the purpose of having the kernel do the leap adjustment is to
avoid such latencies, so I think this is worth fixing.
So in order to properly keep those timers from firing a second early,
this patch modifies the ntp and timekeeping logic so that we keep
enough state so that the update_base_offsets_now accessor, which
provides the hrtimer core the current time, can check and apply the
leapsecond adjustment on the second edge. This prevents the hrtimer
core from expiring timers too early.
This patch does not modify any other time read path, so no additional
overhead is incurred. However, this also means that the leap-second
continues to be applied at tick time for all other read-paths.
Apologies to Richard Cochran, who pushed for similar changes years
ago, which I resisted due to the concerns about the performance
overhead.
While I suspect this isn't extremely critical, folks who care about
strict leap-second correctness will likely want to watch
this. Potentially a -stable candidate eventually.
Originally-suggested-by: Richard Cochran <richardcochran@gmail.com>
Reported-by: Daniel Bristot de Oliveira <bristot@redhat.com>
Reported-by: Prarit Bhargava <prarit@redhat.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Cc: Richard Cochran <richardcochran@gmail.com>
Cc: Jan Kara <jack@suse.cz>
Cc: Jiri Bohac <jbohac@suse.cz>
Cc: Shuah Khan <shuahkh@osg.samsung.com>
Cc: Ingo Molnar <mingo@kernel.org>
Link: http://lkml.kernel.org/r/1434063297-28657-4-git-send-email-john.stultz@linaro.org
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2015-06-12 01:54:55 +03:00
return ret ;
}
2011-11-15 01:18:07 +04:00
2006-10-01 10:28:22 +04:00
/*
2012-03-16 00:04:03 +04:00
* this routine handles the overflow of the microsecond field
*
* The tricky bits of code to handle the accurate clock support
* were provided by Dave Mills ( Mills @ UDEL . EDU ) of NTP fame .
* They were originally developed for SUN and DEC kernels .
* All the kudos should go to Dave for this stuff .
*
* Also handles leap second processing , and returns leap offset
2006-10-01 10:28:22 +04:00
*/
2015-12-13 07:26:42 +03:00
int second_overflow ( time64_t secs )
2006-10-01 10:28:22 +04:00
{
2012-03-16 00:04:03 +04:00
s64 delta ;
2011-11-15 01:48:36 +04:00
int leap = 0 ;
2015-12-13 07:26:42 +03:00
s32 rem ;
2012-03-16 00:04:03 +04:00
/*
* Leap second processing . If in leap - insert state at the end of the
* day , the system clock is set back one second ; if in leap - delete
* state , the system clock is set ahead one second .
*/
2006-10-01 10:28:22 +04:00
switch ( time_state ) {
case TIME_OK :
time: Prevent early expiry of hrtimers[CLOCK_REALTIME] at the leap second edge
Currently, leapsecond adjustments are done at tick time. As a result,
the leapsecond was applied at the first timer tick *after* the
leapsecond (~1-10ms late depending on HZ), rather then exactly on the
second edge.
This was in part historical from back when we were always tick based,
but correcting this since has been avoided since it adds extra
conditional checks in the gettime fastpath, which has performance
overhead.
However, it was recently pointed out that 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.
This isn't quite as bad as it sounds, since behaviorally it is similar
to what is possible w/ ntpd made leapsecond adjustments done w/o using
the kernel discipline. Where due to latencies, timers may fire just
prior to the settimeofday call. (Also, one should note that all
applications using CLOCK_REALTIME timers should always be careful,
since they are prone to quirks from settimeofday() disturbances.)
However, the purpose of having the kernel do the leap adjustment is to
avoid such latencies, so I think this is worth fixing.
So in order to properly keep those timers from firing a second early,
this patch modifies the ntp and timekeeping logic so that we keep
enough state so that the update_base_offsets_now accessor, which
provides the hrtimer core the current time, can check and apply the
leapsecond adjustment on the second edge. This prevents the hrtimer
core from expiring timers too early.
This patch does not modify any other time read path, so no additional
overhead is incurred. However, this also means that the leap-second
continues to be applied at tick time for all other read-paths.
Apologies to Richard Cochran, who pushed for similar changes years
ago, which I resisted due to the concerns about the performance
overhead.
While I suspect this isn't extremely critical, folks who care about
strict leap-second correctness will likely want to watch
this. Potentially a -stable candidate eventually.
Originally-suggested-by: Richard Cochran <richardcochran@gmail.com>
Reported-by: Daniel Bristot de Oliveira <bristot@redhat.com>
Reported-by: Prarit Bhargava <prarit@redhat.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Cc: Richard Cochran <richardcochran@gmail.com>
Cc: Jan Kara <jack@suse.cz>
Cc: Jiri Bohac <jbohac@suse.cz>
Cc: Shuah Khan <shuahkh@osg.samsung.com>
Cc: Ingo Molnar <mingo@kernel.org>
Link: http://lkml.kernel.org/r/1434063297-28657-4-git-send-email-john.stultz@linaro.org
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2015-06-12 01:54:55 +03:00
if ( time_status & STA_INS ) {
2012-03-16 00:04:03 +04:00
time_state = TIME_INS ;
2015-12-13 07:26:42 +03:00
div_s64_rem ( secs , SECS_PER_DAY , & rem ) ;
ntp_next_leap_sec = secs + SECS_PER_DAY - rem ;
time: Prevent early expiry of hrtimers[CLOCK_REALTIME] at the leap second edge
Currently, leapsecond adjustments are done at tick time. As a result,
the leapsecond was applied at the first timer tick *after* the
leapsecond (~1-10ms late depending on HZ), rather then exactly on the
second edge.
This was in part historical from back when we were always tick based,
but correcting this since has been avoided since it adds extra
conditional checks in the gettime fastpath, which has performance
overhead.
However, it was recently pointed out that 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.
This isn't quite as bad as it sounds, since behaviorally it is similar
to what is possible w/ ntpd made leapsecond adjustments done w/o using
the kernel discipline. Where due to latencies, timers may fire just
prior to the settimeofday call. (Also, one should note that all
applications using CLOCK_REALTIME timers should always be careful,
since they are prone to quirks from settimeofday() disturbances.)
However, the purpose of having the kernel do the leap adjustment is to
avoid such latencies, so I think this is worth fixing.
So in order to properly keep those timers from firing a second early,
this patch modifies the ntp and timekeeping logic so that we keep
enough state so that the update_base_offsets_now accessor, which
provides the hrtimer core the current time, can check and apply the
leapsecond adjustment on the second edge. This prevents the hrtimer
core from expiring timers too early.
This patch does not modify any other time read path, so no additional
overhead is incurred. However, this also means that the leap-second
continues to be applied at tick time for all other read-paths.
Apologies to Richard Cochran, who pushed for similar changes years
ago, which I resisted due to the concerns about the performance
overhead.
While I suspect this isn't extremely critical, folks who care about
strict leap-second correctness will likely want to watch
this. Potentially a -stable candidate eventually.
Originally-suggested-by: Richard Cochran <richardcochran@gmail.com>
Reported-by: Daniel Bristot de Oliveira <bristot@redhat.com>
Reported-by: Prarit Bhargava <prarit@redhat.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Cc: Richard Cochran <richardcochran@gmail.com>
Cc: Jan Kara <jack@suse.cz>
Cc: Jiri Bohac <jbohac@suse.cz>
Cc: Shuah Khan <shuahkh@osg.samsung.com>
Cc: Ingo Molnar <mingo@kernel.org>
Link: http://lkml.kernel.org/r/1434063297-28657-4-git-send-email-john.stultz@linaro.org
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2015-06-12 01:54:55 +03:00
} else if ( time_status & STA_DEL ) {
2012-03-16 00:04:03 +04:00
time_state = TIME_DEL ;
2015-12-13 07:26:42 +03:00
div_s64_rem ( secs + 1 , SECS_PER_DAY , & rem ) ;
ntp_next_leap_sec = secs + SECS_PER_DAY - rem ;
time: Prevent early expiry of hrtimers[CLOCK_REALTIME] at the leap second edge
Currently, leapsecond adjustments are done at tick time. As a result,
the leapsecond was applied at the first timer tick *after* the
leapsecond (~1-10ms late depending on HZ), rather then exactly on the
second edge.
This was in part historical from back when we were always tick based,
but correcting this since has been avoided since it adds extra
conditional checks in the gettime fastpath, which has performance
overhead.
However, it was recently pointed out that 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.
This isn't quite as bad as it sounds, since behaviorally it is similar
to what is possible w/ ntpd made leapsecond adjustments done w/o using
the kernel discipline. Where due to latencies, timers may fire just
prior to the settimeofday call. (Also, one should note that all
applications using CLOCK_REALTIME timers should always be careful,
since they are prone to quirks from settimeofday() disturbances.)
However, the purpose of having the kernel do the leap adjustment is to
avoid such latencies, so I think this is worth fixing.
So in order to properly keep those timers from firing a second early,
this patch modifies the ntp and timekeeping logic so that we keep
enough state so that the update_base_offsets_now accessor, which
provides the hrtimer core the current time, can check and apply the
leapsecond adjustment on the second edge. This prevents the hrtimer
core from expiring timers too early.
This patch does not modify any other time read path, so no additional
overhead is incurred. However, this also means that the leap-second
continues to be applied at tick time for all other read-paths.
Apologies to Richard Cochran, who pushed for similar changes years
ago, which I resisted due to the concerns about the performance
overhead.
While I suspect this isn't extremely critical, folks who care about
strict leap-second correctness will likely want to watch
this. Potentially a -stable candidate eventually.
Originally-suggested-by: Richard Cochran <richardcochran@gmail.com>
Reported-by: Daniel Bristot de Oliveira <bristot@redhat.com>
Reported-by: Prarit Bhargava <prarit@redhat.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Cc: Richard Cochran <richardcochran@gmail.com>
Cc: Jan Kara <jack@suse.cz>
Cc: Jiri Bohac <jbohac@suse.cz>
Cc: Shuah Khan <shuahkh@osg.samsung.com>
Cc: Ingo Molnar <mingo@kernel.org>
Link: http://lkml.kernel.org/r/1434063297-28657-4-git-send-email-john.stultz@linaro.org
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2015-06-12 01:54:55 +03:00
}
2006-10-01 10:28:22 +04:00
break ;
case TIME_INS :
time: Prevent early expiry of hrtimers[CLOCK_REALTIME] at the leap second edge
Currently, leapsecond adjustments are done at tick time. As a result,
the leapsecond was applied at the first timer tick *after* the
leapsecond (~1-10ms late depending on HZ), rather then exactly on the
second edge.
This was in part historical from back when we were always tick based,
but correcting this since has been avoided since it adds extra
conditional checks in the gettime fastpath, which has performance
overhead.
However, it was recently pointed out that 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.
This isn't quite as bad as it sounds, since behaviorally it is similar
to what is possible w/ ntpd made leapsecond adjustments done w/o using
the kernel discipline. Where due to latencies, timers may fire just
prior to the settimeofday call. (Also, one should note that all
applications using CLOCK_REALTIME timers should always be careful,
since they are prone to quirks from settimeofday() disturbances.)
However, the purpose of having the kernel do the leap adjustment is to
avoid such latencies, so I think this is worth fixing.
So in order to properly keep those timers from firing a second early,
this patch modifies the ntp and timekeeping logic so that we keep
enough state so that the update_base_offsets_now accessor, which
provides the hrtimer core the current time, can check and apply the
leapsecond adjustment on the second edge. This prevents the hrtimer
core from expiring timers too early.
This patch does not modify any other time read path, so no additional
overhead is incurred. However, this also means that the leap-second
continues to be applied at tick time for all other read-paths.
Apologies to Richard Cochran, who pushed for similar changes years
ago, which I resisted due to the concerns about the performance
overhead.
While I suspect this isn't extremely critical, folks who care about
strict leap-second correctness will likely want to watch
this. Potentially a -stable candidate eventually.
Originally-suggested-by: Richard Cochran <richardcochran@gmail.com>
Reported-by: Daniel Bristot de Oliveira <bristot@redhat.com>
Reported-by: Prarit Bhargava <prarit@redhat.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Cc: Richard Cochran <richardcochran@gmail.com>
Cc: Jan Kara <jack@suse.cz>
Cc: Jiri Bohac <jbohac@suse.cz>
Cc: Shuah Khan <shuahkh@osg.samsung.com>
Cc: Ingo Molnar <mingo@kernel.org>
Link: http://lkml.kernel.org/r/1434063297-28657-4-git-send-email-john.stultz@linaro.org
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2015-06-12 01:54:55 +03:00
if ( ! ( time_status & STA_INS ) ) {
ntp_next_leap_sec = TIME64_MAX ;
2012-07-13 09:21:50 +04:00
time_state = TIME_OK ;
2015-12-13 07:26:42 +03:00
} else if ( secs = = ntp_next_leap_sec ) {
2012-03-16 00:04:03 +04:00
leap = - 1 ;
time_state = TIME_OOP ;
printk ( KERN_NOTICE
" Clock: inserting leap second 23:59:60 UTC \n " ) ;
}
2006-10-01 10:28:22 +04:00
break ;
case TIME_DEL :
time: Prevent early expiry of hrtimers[CLOCK_REALTIME] at the leap second edge
Currently, leapsecond adjustments are done at tick time. As a result,
the leapsecond was applied at the first timer tick *after* the
leapsecond (~1-10ms late depending on HZ), rather then exactly on the
second edge.
This was in part historical from back when we were always tick based,
but correcting this since has been avoided since it adds extra
conditional checks in the gettime fastpath, which has performance
overhead.
However, it was recently pointed out that 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.
This isn't quite as bad as it sounds, since behaviorally it is similar
to what is possible w/ ntpd made leapsecond adjustments done w/o using
the kernel discipline. Where due to latencies, timers may fire just
prior to the settimeofday call. (Also, one should note that all
applications using CLOCK_REALTIME timers should always be careful,
since they are prone to quirks from settimeofday() disturbances.)
However, the purpose of having the kernel do the leap adjustment is to
avoid such latencies, so I think this is worth fixing.
So in order to properly keep those timers from firing a second early,
this patch modifies the ntp and timekeeping logic so that we keep
enough state so that the update_base_offsets_now accessor, which
provides the hrtimer core the current time, can check and apply the
leapsecond adjustment on the second edge. This prevents the hrtimer
core from expiring timers too early.
This patch does not modify any other time read path, so no additional
overhead is incurred. However, this also means that the leap-second
continues to be applied at tick time for all other read-paths.
Apologies to Richard Cochran, who pushed for similar changes years
ago, which I resisted due to the concerns about the performance
overhead.
While I suspect this isn't extremely critical, folks who care about
strict leap-second correctness will likely want to watch
this. Potentially a -stable candidate eventually.
Originally-suggested-by: Richard Cochran <richardcochran@gmail.com>
Reported-by: Daniel Bristot de Oliveira <bristot@redhat.com>
Reported-by: Prarit Bhargava <prarit@redhat.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Cc: Richard Cochran <richardcochran@gmail.com>
Cc: Jan Kara <jack@suse.cz>
Cc: Jiri Bohac <jbohac@suse.cz>
Cc: Shuah Khan <shuahkh@osg.samsung.com>
Cc: Ingo Molnar <mingo@kernel.org>
Link: http://lkml.kernel.org/r/1434063297-28657-4-git-send-email-john.stultz@linaro.org
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2015-06-12 01:54:55 +03:00
if ( ! ( time_status & STA_DEL ) ) {
ntp_next_leap_sec = TIME64_MAX ;
2012-07-13 09:21:50 +04:00
time_state = TIME_OK ;
2015-12-13 07:26:42 +03:00
} else if ( secs = = ntp_next_leap_sec ) {
2012-03-16 00:04:03 +04:00
leap = 1 ;
time: Prevent early expiry of hrtimers[CLOCK_REALTIME] at the leap second edge
Currently, leapsecond adjustments are done at tick time. As a result,
the leapsecond was applied at the first timer tick *after* the
leapsecond (~1-10ms late depending on HZ), rather then exactly on the
second edge.
This was in part historical from back when we were always tick based,
but correcting this since has been avoided since it adds extra
conditional checks in the gettime fastpath, which has performance
overhead.
However, it was recently pointed out that 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.
This isn't quite as bad as it sounds, since behaviorally it is similar
to what is possible w/ ntpd made leapsecond adjustments done w/o using
the kernel discipline. Where due to latencies, timers may fire just
prior to the settimeofday call. (Also, one should note that all
applications using CLOCK_REALTIME timers should always be careful,
since they are prone to quirks from settimeofday() disturbances.)
However, the purpose of having the kernel do the leap adjustment is to
avoid such latencies, so I think this is worth fixing.
So in order to properly keep those timers from firing a second early,
this patch modifies the ntp and timekeeping logic so that we keep
enough state so that the update_base_offsets_now accessor, which
provides the hrtimer core the current time, can check and apply the
leapsecond adjustment on the second edge. This prevents the hrtimer
core from expiring timers too early.
This patch does not modify any other time read path, so no additional
overhead is incurred. However, this also means that the leap-second
continues to be applied at tick time for all other read-paths.
Apologies to Richard Cochran, who pushed for similar changes years
ago, which I resisted due to the concerns about the performance
overhead.
While I suspect this isn't extremely critical, folks who care about
strict leap-second correctness will likely want to watch
this. Potentially a -stable candidate eventually.
Originally-suggested-by: Richard Cochran <richardcochran@gmail.com>
Reported-by: Daniel Bristot de Oliveira <bristot@redhat.com>
Reported-by: Prarit Bhargava <prarit@redhat.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Cc: Richard Cochran <richardcochran@gmail.com>
Cc: Jan Kara <jack@suse.cz>
Cc: Jiri Bohac <jbohac@suse.cz>
Cc: Shuah Khan <shuahkh@osg.samsung.com>
Cc: Ingo Molnar <mingo@kernel.org>
Link: http://lkml.kernel.org/r/1434063297-28657-4-git-send-email-john.stultz@linaro.org
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2015-06-12 01:54:55 +03:00
ntp_next_leap_sec = TIME64_MAX ;
2012-03-16 00:04:03 +04:00
time_state = TIME_WAIT ;
printk ( KERN_NOTICE
" Clock: deleting leap second 23:59:59 UTC \n " ) ;
}
2006-10-01 10:28:22 +04:00
break ;
case TIME_OOP :
time: Prevent early expiry of hrtimers[CLOCK_REALTIME] at the leap second edge
Currently, leapsecond adjustments are done at tick time. As a result,
the leapsecond was applied at the first timer tick *after* the
leapsecond (~1-10ms late depending on HZ), rather then exactly on the
second edge.
This was in part historical from back when we were always tick based,
but correcting this since has been avoided since it adds extra
conditional checks in the gettime fastpath, which has performance
overhead.
However, it was recently pointed out that 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.
This isn't quite as bad as it sounds, since behaviorally it is similar
to what is possible w/ ntpd made leapsecond adjustments done w/o using
the kernel discipline. Where due to latencies, timers may fire just
prior to the settimeofday call. (Also, one should note that all
applications using CLOCK_REALTIME timers should always be careful,
since they are prone to quirks from settimeofday() disturbances.)
However, the purpose of having the kernel do the leap adjustment is to
avoid such latencies, so I think this is worth fixing.
So in order to properly keep those timers from firing a second early,
this patch modifies the ntp and timekeeping logic so that we keep
enough state so that the update_base_offsets_now accessor, which
provides the hrtimer core the current time, can check and apply the
leapsecond adjustment on the second edge. This prevents the hrtimer
core from expiring timers too early.
This patch does not modify any other time read path, so no additional
overhead is incurred. However, this also means that the leap-second
continues to be applied at tick time for all other read-paths.
Apologies to Richard Cochran, who pushed for similar changes years
ago, which I resisted due to the concerns about the performance
overhead.
While I suspect this isn't extremely critical, folks who care about
strict leap-second correctness will likely want to watch
this. Potentially a -stable candidate eventually.
Originally-suggested-by: Richard Cochran <richardcochran@gmail.com>
Reported-by: Daniel Bristot de Oliveira <bristot@redhat.com>
Reported-by: Prarit Bhargava <prarit@redhat.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Cc: Richard Cochran <richardcochran@gmail.com>
Cc: Jan Kara <jack@suse.cz>
Cc: Jiri Bohac <jbohac@suse.cz>
Cc: Shuah Khan <shuahkh@osg.samsung.com>
Cc: Ingo Molnar <mingo@kernel.org>
Link: http://lkml.kernel.org/r/1434063297-28657-4-git-send-email-john.stultz@linaro.org
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2015-06-12 01:54:55 +03:00
ntp_next_leap_sec = TIME64_MAX ;
2006-10-01 10:28:22 +04:00
time_state = TIME_WAIT ;
2012-03-16 00:04:03 +04:00
break ;
2006-10-01 10:28:22 +04:00
case TIME_WAIT :
if ( ! ( time_status & ( STA_INS | STA_DEL ) ) )
2008-05-01 15:34:32 +04:00
time_state = TIME_OK ;
2008-05-01 15:34:41 +04:00
break ;
}
2011-11-15 01:48:36 +04:00
2008-05-01 15:34:41 +04:00
/* Bump the maxerror field */
time_maxerror + = MAXFREQ / NSEC_PER_USEC ;
if ( time_maxerror > NTP_PHASE_LIMIT ) {
time_maxerror = NTP_PHASE_LIMIT ;
time_status | = STA_UNSYNC ;
2006-10-01 10:28:22 +04:00
}
2011-01-13 04:00:56 +03:00
/* Compute the phase adjustment for the next second */
2009-02-22 18:06:58 +03:00
tick_length = tick_length_base ;
2011-01-13 04:00:56 +03:00
delta = ntp_offset_chunk ( time_offset ) ;
2009-02-22 18:06:58 +03:00
time_offset - = delta ;
tick_length + = delta ;
2006-10-01 10:28:22 +04:00
2011-01-13 04:00:56 +03:00
/* Check PPS signal */
pps_dec_valid ( ) ;
2009-02-22 14:06:57 +03:00
if ( ! time_adjust )
2011-11-15 01:48:36 +04:00
goto out ;
2009-02-22 14:06:57 +03:00
if ( time_adjust > MAX_TICKADJ ) {
time_adjust - = MAX_TICKADJ ;
tick_length + = MAX_TICKADJ_SCALED ;
2011-11-15 01:48:36 +04:00
goto out ;
2006-10-01 10:28:22 +04:00
}
2009-02-22 14:06:57 +03:00
if ( time_adjust < - MAX_TICKADJ ) {
time_adjust + = MAX_TICKADJ ;
tick_length - = MAX_TICKADJ_SCALED ;
2011-11-15 01:48:36 +04:00
goto out ;
2009-02-22 14:06:57 +03:00
}
tick_length + = ( s64 ) ( time_adjust * NSEC_PER_USEC / NTP_INTERVAL_FREQ )
< < NTP_SCALE_SHIFT ;
time_adjust = 0 ;
2012-03-16 00:04:03 +04:00
2011-11-15 01:48:36 +04:00
out :
2012-03-16 00:04:03 +04:00
return leap ;
2006-10-01 10:28:22 +04:00
}
2017-10-13 20:54:33 +03:00
static void sync_hw_clock ( struct work_struct * work ) ;
static DECLARE_DELAYED_WORK ( sync_work , sync_hw_clock ) ;
static void sched_sync_hw_clock ( struct timespec64 now ,
unsigned long target_nsec , bool fail )
{
struct timespec64 next ;
getnstimeofday64 ( & next ) ;
if ( ! fail )
next . tv_sec = 659 ;
else {
/*
* Try again as soon as possible . Delaying long periods
* decreases the accuracy of the work queue timer . Due to this
* the algorithm is very likely to require a short - sleep retry
* after the above long sleep to synchronize ts_nsec .
*/
next . tv_sec = 0 ;
}
/* Compute the needed delay that will get to tv_nsec == target_nsec */
next . tv_nsec = target_nsec - next . tv_nsec ;
if ( next . tv_nsec < = 0 )
next . tv_nsec + = NSEC_PER_SEC ;
if ( next . tv_nsec > = NSEC_PER_SEC ) {
next . tv_sec + + ;
next . tv_nsec - = NSEC_PER_SEC ;
}
queue_delayed_work ( system_power_efficient_wq , & sync_work ,
timespec64_to_jiffies ( & next ) ) ;
}
static void sync_rtc_clock ( void )
{
unsigned long target_nsec ;
struct timespec64 adjust , now ;
int rc ;
if ( ! IS_ENABLED ( CONFIG_RTC_SYSTOHC ) )
return ;
getnstimeofday64 ( & now ) ;
adjust = now ;
if ( persistent_clock_is_local )
adjust . tv_sec - = ( sys_tz . tz_minuteswest * 60 ) ;
/*
* The current RTC in use will provide the target_nsec it wants to be
* called at , and does rtc_tv_nsec_ok internally .
*/
rc = rtc_set_ntp_time ( adjust , & target_nsec ) ;
if ( rc = = - ENODEV )
return ;
sched_sync_hw_clock ( now , target_nsec , rc ) ;
}
2015-04-02 06:34:23 +03:00
# ifdef CONFIG_GENERIC_CMOS_UPDATE
2015-07-26 13:45:39 +03:00
int __weak update_persistent_clock ( struct timespec now )
{
return - ENODEV ;
}
2015-04-02 06:34:23 +03:00
int __weak update_persistent_clock64 ( struct timespec64 now64 )
{
struct timespec now ;
now = timespec64_to_timespec ( now64 ) ;
return update_persistent_clock ( now ) ;
}
# endif
2017-10-13 20:54:33 +03:00
static bool sync_cmos_clock ( void )
2007-07-21 15:37:37 +04:00
{
2017-10-13 20:54:33 +03:00
static bool no_cmos ;
2014-07-17 01:04:04 +04:00
struct timespec64 now ;
2017-10-13 20:54:33 +03:00
struct timespec64 adjust ;
int rc = - EPROTO ;
long target_nsec = NSEC_PER_SEC / 2 ;
if ( ! IS_ENABLED ( CONFIG_GENERIC_CMOS_UPDATE ) )
return false ;
if ( no_cmos )
return false ;
2007-07-21 15:37:37 +04:00
/*
2017-10-13 20:54:33 +03:00
* Historically update_persistent_clock64 ( ) has followed x86
* semantics , which match the MC146818A / etc RTC . This RTC will store
* ' adjust ' and then in .5 s it will advance once second .
*
* Architectures are strongly encouraged to use rtclib and not
* implement this legacy API .
2007-07-21 15:37:37 +04:00
*/
2014-07-17 01:04:04 +04:00
getnstimeofday64 ( & now ) ;
2017-10-13 20:54:33 +03:00
if ( rtc_tv_nsec_ok ( - 1 * target_nsec , & adjust , & now ) ) {
2013-02-09 02:59:53 +04:00
if ( persistent_clock_is_local )
adjust . tv_sec - = ( sys_tz . tz_minuteswest * 60 ) ;
2017-10-13 20:54:33 +03:00
rc = update_persistent_clock64 ( adjust ) ;
/*
* The machine does not support update_persistent_clock64 even
* though it defines CONFIG_GENERIC_CMOS_UPDATE .
*/
if ( rc = = - ENODEV ) {
no_cmos = true ;
return false ;
}
2012-12-18 01:30:53 +04:00
}
2007-07-21 15:37:37 +04:00
2017-10-13 20:54:33 +03:00
sched_sync_hw_clock ( now , target_nsec , rc ) ;
return true ;
}
2007-07-21 15:37:37 +04:00
2017-10-13 20:54:33 +03:00
/*
* If we have an externally synchronized Linux clock , then update RTC clock
* accordingly every ~ 11 minutes . Generally RTCs can only store second
* precision , but many RTCs will adjust the phase of their second tick to
* match the moment of update . This infrastructure arranges to call to the RTC
* set at the correct moment to phase synchronize the RTC second tick over
* with the kernel clock .
*/
static void sync_hw_clock ( struct work_struct * work )
{
if ( ! ntp_synced ( ) )
return ;
2007-07-21 15:37:37 +04:00
2017-10-13 20:54:33 +03:00
if ( sync_cmos_clock ( ) )
return ;
sync_rtc_clock ( ) ;
2007-07-21 15:37:37 +04:00
}
2013-09-12 03:50:56 +04:00
void ntp_notify_cmos_timer ( void )
2006-10-01 10:28:22 +04:00
{
2017-10-13 20:54:33 +03:00
if ( ! ntp_synced ( ) )
return ;
2007-07-21 15:37:37 +04:00
2017-10-13 20:54:33 +03:00
if ( IS_ENABLED ( CONFIG_GENERIC_CMOS_UPDATE ) | |
IS_ENABLED ( CONFIG_RTC_SYSTOHC ) )
queue_delayed_work ( system_power_efficient_wq , & sync_work , 0 ) ;
}
2009-02-22 17:15:32 +03:00
/*
* Propagate a new txc - > status value into the NTP state :
*/
2014-07-17 01:04:01 +04:00
static inline void process_adj_status ( struct timex * txc , struct timespec64 * ts )
2009-02-22 17:15:32 +03:00
{
if ( ( time_status & STA_PLL ) & & ! ( txc - > status & STA_PLL ) ) {
time_state = TIME_OK ;
time_status = STA_UNSYNC ;
time: Prevent early expiry of hrtimers[CLOCK_REALTIME] at the leap second edge
Currently, leapsecond adjustments are done at tick time. As a result,
the leapsecond was applied at the first timer tick *after* the
leapsecond (~1-10ms late depending on HZ), rather then exactly on the
second edge.
This was in part historical from back when we were always tick based,
but correcting this since has been avoided since it adds extra
conditional checks in the gettime fastpath, which has performance
overhead.
However, it was recently pointed out that 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.
This isn't quite as bad as it sounds, since behaviorally it is similar
to what is possible w/ ntpd made leapsecond adjustments done w/o using
the kernel discipline. Where due to latencies, timers may fire just
prior to the settimeofday call. (Also, one should note that all
applications using CLOCK_REALTIME timers should always be careful,
since they are prone to quirks from settimeofday() disturbances.)
However, the purpose of having the kernel do the leap adjustment is to
avoid such latencies, so I think this is worth fixing.
So in order to properly keep those timers from firing a second early,
this patch modifies the ntp and timekeeping logic so that we keep
enough state so that the update_base_offsets_now accessor, which
provides the hrtimer core the current time, can check and apply the
leapsecond adjustment on the second edge. This prevents the hrtimer
core from expiring timers too early.
This patch does not modify any other time read path, so no additional
overhead is incurred. However, this also means that the leap-second
continues to be applied at tick time for all other read-paths.
Apologies to Richard Cochran, who pushed for similar changes years
ago, which I resisted due to the concerns about the performance
overhead.
While I suspect this isn't extremely critical, folks who care about
strict leap-second correctness will likely want to watch
this. Potentially a -stable candidate eventually.
Originally-suggested-by: Richard Cochran <richardcochran@gmail.com>
Reported-by: Daniel Bristot de Oliveira <bristot@redhat.com>
Reported-by: Prarit Bhargava <prarit@redhat.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Cc: Richard Cochran <richardcochran@gmail.com>
Cc: Jan Kara <jack@suse.cz>
Cc: Jiri Bohac <jbohac@suse.cz>
Cc: Shuah Khan <shuahkh@osg.samsung.com>
Cc: Ingo Molnar <mingo@kernel.org>
Link: http://lkml.kernel.org/r/1434063297-28657-4-git-send-email-john.stultz@linaro.org
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2015-06-12 01:54:55 +03:00
ntp_next_leap_sec = TIME64_MAX ;
2011-01-13 04:00:56 +03:00
/* restart PPS frequency calibration */
pps_reset_freq_interval ( ) ;
2009-02-22 17:15:32 +03:00
}
/*
* If we turn on PLL adjustments then reset the
* reference time to current time .
*/
if ( ! ( time_status & STA_PLL ) & & ( txc - > status & STA_PLL ) )
2015-12-13 07:24:19 +03:00
time_reftime = __ktime_get_real_seconds ( ) ;
2009-02-22 17:15:32 +03:00
2009-02-26 20:46:14 +03:00
/* only set allowed bits */
time_status & = STA_RONLY ;
2009-02-22 17:15:32 +03:00
time_status | = txc - > status & ~ STA_RONLY ;
}
2012-04-27 12:12:41 +04:00
2013-03-22 22:52:03 +04:00
2012-05-03 23:30:07 +04:00
static inline void process_adjtimex_modes ( struct timex * txc ,
2014-07-17 01:04:01 +04:00
struct timespec64 * ts ,
2012-05-03 23:30:07 +04:00
s32 * time_tai )
2009-02-22 17:15:32 +03:00
{
if ( txc - > modes & ADJ_STATUS )
process_adj_status ( txc , ts ) ;
if ( txc - > modes & ADJ_NANO )
time_status | = STA_NANO ;
2009-02-22 17:35:18 +03:00
2009-02-22 17:15:32 +03:00
if ( txc - > modes & ADJ_MICRO )
time_status & = ~ STA_NANO ;
if ( txc - > modes & ADJ_FREQUENCY ) {
2009-02-22 17:48:43 +03:00
time_freq = txc - > freq * PPM_SCALE ;
2009-02-22 17:15:32 +03:00
time_freq = min ( time_freq , MAXFREQ_SCALED ) ;
time_freq = max ( time_freq , - MAXFREQ_SCALED ) ;
2011-01-13 04:00:56 +03:00
/* update pps_freq */
pps_set_freq ( time_freq ) ;
2009-02-22 17:15:32 +03:00
}
if ( txc - > modes & ADJ_MAXERROR )
time_maxerror = txc - > maxerror ;
2009-02-22 17:35:18 +03:00
2009-02-22 17:15:32 +03:00
if ( txc - > modes & ADJ_ESTERROR )
time_esterror = txc - > esterror ;
if ( txc - > modes & ADJ_TIMECONST ) {
time_constant = txc - > constant ;
if ( ! ( time_status & STA_NANO ) )
time_constant + = 4 ;
time_constant = min ( time_constant , ( long ) MAXTC ) ;
time_constant = max ( time_constant , 0l ) ;
}
if ( txc - > modes & ADJ_TAI & & txc - > constant > 0 )
2012-05-03 23:30:07 +04:00
* time_tai = txc - > constant ;
2009-02-22 17:15:32 +03:00
if ( txc - > modes & ADJ_OFFSET )
ntp_update_offset ( txc - > offset ) ;
2009-02-22 17:35:18 +03:00
2009-02-22 17:15:32 +03:00
if ( txc - > modes & ADJ_TICK )
tick_usec = txc - > tick ;
if ( txc - > modes & ( ADJ_TICK | ADJ_FREQUENCY | ADJ_OFFSET ) )
ntp_update_frequency ( ) ;
}
2013-03-22 22:59:04 +04:00
/*
* adjtimex mainly allows reading ( and writing , if superuser ) of
* kernel time - keeping variables . used by xntpd .
*/
2014-07-17 01:04:01 +04:00
int __do_adjtimex ( struct timex * txc , struct timespec64 * ts , s32 * time_tai )
2013-03-22 22:59:04 +04:00
{
int result ;
2008-08-21 03:46:08 +04:00
if ( txc - > modes & ADJ_ADJTIME ) {
long save_adjust = time_adjust ;
if ( ! ( txc - > modes & ADJ_OFFSET_READONLY ) ) {
/* adjtime() is independent from ntp_adjtime() */
time_adjust = txc - > offset ;
ntp_update_frequency ( ) ;
}
txc - > offset = save_adjust ;
2009-02-22 17:35:18 +03:00
} else {
2008-05-01 15:34:32 +04:00
2009-02-22 17:35:18 +03:00
/* If there are input parameters, then process them: */
if ( txc - > modes )
2013-03-22 23:28:15 +04:00
process_adjtimex_modes ( txc , ts , time_tai ) ;
2008-05-01 15:34:33 +04:00
2009-02-22 17:35:18 +03:00
txc - > offset = shift_right ( time_offset * NTP_INTERVAL_FREQ ,
2008-08-21 03:46:08 +04:00
NTP_SCALE_SHIFT ) ;
2009-02-22 17:35:18 +03:00
if ( ! ( time_status & STA_NANO ) )
txc - > offset / = NSEC_PER_USEC ;
}
2008-08-21 03:46:08 +04:00
2008-05-01 15:34:33 +04:00
result = time_state ; /* mostly `TIME_OK' */
2011-01-13 04:00:56 +03:00
/* check for errors */
if ( is_error_status ( time_status ) )
2006-10-01 10:28:22 +04:00
result = TIME_ERROR ;
2008-09-23 01:42:44 +04:00
txc - > freq = shift_right ( ( time_freq > > PPM_SCALE_INV_SHIFT ) *
2009-02-22 17:48:43 +03:00
PPM_SCALE_INV , NTP_SCALE_SHIFT ) ;
2006-10-01 10:28:22 +04:00
txc - > maxerror = time_maxerror ;
txc - > esterror = time_esterror ;
txc - > status = time_status ;
txc - > constant = time_constant ;
2006-10-01 10:28:29 +04:00
txc - > precision = 1 ;
2008-05-01 15:34:34 +04:00
txc - > tolerance = MAXFREQ_SCALED / PPM_SCALE ;
2006-10-01 10:28:22 +04:00
txc - > tick = tick_usec ;
2013-03-22 23:28:15 +04:00
txc - > tai = * time_tai ;
2006-10-01 10:28:22 +04:00
2011-01-13 04:00:56 +03:00
/* fill PPS status fields */
pps_fill_timex ( txc ) ;
2009-02-22 17:35:18 +03:00
2014-07-17 01:04:01 +04:00
txc - > time . tv_sec = ( time_t ) ts - > tv_sec ;
2013-03-22 23:28:15 +04:00
txc - > time . tv_usec = ts - > tv_nsec ;
2008-05-01 15:34:33 +04:00
if ( ! ( time_status & STA_NANO ) )
txc - > time . tv_usec / = NSEC_PER_USEC ;
2008-05-01 15:34:32 +04:00
2015-06-12 01:54:56 +03:00
/* 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 ;
}
}
2008-05-01 15:34:32 +04:00
return result ;
2006-10-01 10:28:22 +04:00
}
time: remove obsolete CLOCK_TICK_ADJUST
The first version of the ntp_interval/tick_length inconsistent usage patch was
recently merged as bbe4d18ac2e058c56adb0cd71f49d9ed3216a405
http://git.kernel.org/gitweb.cgi?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=bbe4d18ac2e058c56adb0cd71f49d9ed3216a405
While the fix did greatly improve the situation, it was correctly pointed out
by Roman that it does have a small bug: If the users change clocksources after
the system has been running and NTP has made corrections, the correctoins made
against the old clocksource will be applied against the new clocksource,
causing error.
The second attempt, which corrects the issue in the NTP_INTERVAL_LENGTH
definition has also made it up-stream as commit
e13a2e61dd5152f5499d2003470acf9c838eab84
http://git.kernel.org/gitweb.cgi?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=e13a2e61dd5152f5499d2003470acf9c838eab84
Roman has correctly pointed out that CLOCK_TICK_ADJUST is calculated
based on the PIT's frequency, and isn't really relevant to non-PIT
driven clocksources (that is, clocksources other then jiffies and pit).
This patch reverts both of those changes, and simply removes
CLOCK_TICK_ADJUST.
This does remove the granularity error correction for users of PIT and Jiffies
clocksource users, but the granularity error but for the majority of users, it
should be within the 500ppm range NTP can accommodate for.
For systems that have granularity errors greater then 500ppm, the
"ntp_tick_adj=" boot option can be used to compensate.
[johnstul@us.ibm.com: provided changelog]
[mattilinnanvuori@yahoo.com: maek ntp_tick_adj static]
Signed-off-by: Roman Zippel <zippel@linux-m68k.org>
Acked-by: john stultz <johnstul@us.ibm.com>
Signed-off-by: Matti Linnanvuori <mattilinnanvuori@yahoo.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Cc: mingo@elte.hu
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2008-03-05 02:14:26 +03:00
2011-01-13 04:00:56 +03:00
# ifdef CONFIG_NTP_PPS
/* actually struct pps_normtime is good old struct timespec, but it is
* semantically different ( and it is the reason why it was invented ) :
* pps_normtime . nsec has a range of ( - NSEC_PER_SEC / 2 , NSEC_PER_SEC / 2 ]
* while timespec . tv_nsec has a range of [ 0 , NSEC_PER_SEC ) */
struct pps_normtime {
2015-09-28 23:21:28 +03:00
s64 sec ; /* seconds */
2011-01-13 04:00:56 +03:00
long nsec ; /* nanoseconds */
} ;
/* normalize the timestamp so that nsec is in the
( - NSEC_PER_SEC / 2 , NSEC_PER_SEC / 2 ] interval */
2015-09-28 23:21:28 +03:00
static inline struct pps_normtime pps_normalize_ts ( struct timespec64 ts )
2011-01-13 04:00:56 +03:00
{
struct pps_normtime norm = {
. sec = ts . tv_sec ,
. nsec = ts . tv_nsec
} ;
if ( norm . nsec > ( NSEC_PER_SEC > > 1 ) ) {
norm . nsec - = NSEC_PER_SEC ;
norm . sec + + ;
}
return norm ;
}
/* get current phase correction and jitter */
static inline long pps_phase_filter_get ( long * jitter )
{
* jitter = pps_tf [ 0 ] - pps_tf [ 1 ] ;
if ( * jitter < 0 )
* jitter = - * jitter ;
/* TODO: test various filters */
return pps_tf [ 0 ] ;
}
/* add the sample to the phase filter */
static inline void pps_phase_filter_add ( long err )
{
pps_tf [ 2 ] = pps_tf [ 1 ] ;
pps_tf [ 1 ] = pps_tf [ 0 ] ;
pps_tf [ 0 ] = err ;
}
/* decrease frequency calibration interval length.
* It is halved after four consecutive unstable intervals .
*/
static inline void pps_dec_freq_interval ( void )
{
if ( - - pps_intcnt < = - PPS_INTCOUNT ) {
pps_intcnt = - PPS_INTCOUNT ;
if ( pps_shift > PPS_INTMIN ) {
pps_shift - - ;
pps_intcnt = 0 ;
}
}
}
/* increase frequency calibration interval length.
* It is doubled after four consecutive stable intervals .
*/
static inline void pps_inc_freq_interval ( void )
{
if ( + + pps_intcnt > = PPS_INTCOUNT ) {
pps_intcnt = PPS_INTCOUNT ;
if ( pps_shift < PPS_INTMAX ) {
pps_shift + + ;
pps_intcnt = 0 ;
}
}
}
/* update clock frequency based on MONOTONIC_RAW clock PPS signal
* timestamps
*
* At the end of the calibration interval the difference between the
* first and last MONOTONIC_RAW clock timestamps divided by the length
* of the interval becomes the frequency update . If the interval was
* too long , the data are discarded .
* Returns the difference between old and new frequency values .
*/
static long hardpps_update_freq ( struct pps_normtime freq_norm )
{
long delta , delta_mod ;
s64 ftemp ;
/* check if the frequency interval was too long */
if ( freq_norm . sec > ( 2 < < pps_shift ) ) {
time_status | = STA_PPSERROR ;
pps_errcnt + + ;
pps_dec_freq_interval ( ) ;
2014-06-05 03:11:43 +04:00
printk_deferred ( KERN_ERR
2015-09-28 23:21:28 +03:00
" hardpps: PPSERROR: interval too long - %lld s \n " ,
2014-06-05 03:11:43 +04:00
freq_norm . sec ) ;
2011-01-13 04:00:56 +03:00
return 0 ;
}
/* here the raw frequency offset and wander (stability) is
* calculated . If the wander is less than the wander threshold
* the interval is increased ; otherwise it is decreased .
*/
ftemp = div_s64 ( ( ( s64 ) ( - freq_norm . nsec ) ) < < NTP_SCALE_SHIFT ,
freq_norm . sec ) ;
delta = shift_right ( ftemp - pps_freq , NTP_SCALE_SHIFT ) ;
pps_freq = ftemp ;
if ( delta > PPS_MAXWANDER | | delta < - PPS_MAXWANDER ) {
2014-06-05 03:11:43 +04:00
printk_deferred ( KERN_WARNING
" hardpps: PPSWANDER: change=%ld \n " , delta ) ;
2011-01-13 04:00:56 +03:00
time_status | = STA_PPSWANDER ;
pps_stbcnt + + ;
pps_dec_freq_interval ( ) ;
} else { /* good sample */
pps_inc_freq_interval ( ) ;
}
/* the stability metric is calculated as the average of recent
* frequency changes , but is used only for performance
* monitoring
*/
delta_mod = delta ;
if ( delta_mod < 0 )
delta_mod = - delta_mod ;
pps_stabil + = ( div_s64 ( ( ( s64 ) delta_mod ) < <
( NTP_SCALE_SHIFT - SHIFT_USEC ) ,
NSEC_PER_USEC ) - pps_stabil ) > > PPS_INTMIN ;
/* if enabled, the system clock frequency is updated */
if ( ( time_status & STA_PPSFREQ ) ! = 0 & &
( time_status & STA_FREQHOLD ) = = 0 ) {
time_freq = pps_freq ;
ntp_update_frequency ( ) ;
}
return delta ;
}
/* correct REALTIME clock phase error against PPS signal */
static void hardpps_update_phase ( long error )
{
long correction = - error ;
long jitter ;
/* add the sample to the median filter */
pps_phase_filter_add ( correction ) ;
correction = pps_phase_filter_get ( & jitter ) ;
/* Nominal jitter is due to PPS signal noise. If it exceeds the
* threshold , the sample is discarded ; otherwise , if so enabled ,
* the time offset is updated .
*/
if ( jitter > ( pps_jitter < < PPS_POPCORN ) ) {
2014-06-05 03:11:43 +04:00
printk_deferred ( KERN_WARNING
" hardpps: PPSJITTER: jitter=%ld, limit=%ld \n " ,
jitter , ( pps_jitter < < PPS_POPCORN ) ) ;
2011-01-13 04:00:56 +03:00
time_status | = STA_PPSJITTER ;
pps_jitcnt + + ;
} else if ( time_status & STA_PPSTIME ) {
/* correct the time using the phase offset */
time_offset = div_s64 ( ( ( s64 ) correction ) < < NTP_SCALE_SHIFT ,
NTP_INTERVAL_FREQ ) ;
/* cancel running adjtime() */
time_adjust = 0 ;
}
/* update jitter */
pps_jitter + = ( jitter - pps_jitter ) > > PPS_INTMIN ;
}
/*
2013-03-22 22:31:29 +04:00
* __hardpps ( ) - discipline CPU clock oscillator to external PPS signal
2011-01-13 04:00:56 +03:00
*
* This routine is called at each PPS signal arrival in order to
* discipline the CPU clock oscillator to the PPS signal . It takes two
* parameters : REALTIME and MONOTONIC_RAW clock timestamps . The former
* is used to correct clock phase error and the latter is used to
* correct the frequency .
*
* This code is based on David Mills ' s reference nanokernel
* implementation . It was mostly rewritten but keeps the same idea .
*/
2015-09-28 23:21:28 +03:00
void __hardpps ( const struct timespec64 * phase_ts , const struct timespec64 * raw_ts )
2011-01-13 04:00:56 +03:00
{
struct pps_normtime pts_norm , freq_norm ;
pts_norm = pps_normalize_ts ( * phase_ts ) ;
/* clear the error bits, they will be set again if needed */
time_status & = ~ ( STA_PPSJITTER | STA_PPSWANDER | STA_PPSERROR ) ;
/* indicate signal presence */
time_status | = STA_PPSSIGNAL ;
pps_valid = PPS_VALID ;
/* when called for the first time,
* just start the frequency interval */
if ( unlikely ( pps_fbase . tv_sec = = 0 ) ) {
pps_fbase = * raw_ts ;
return ;
}
/* ok, now we have a base for frequency calculation */
2015-09-28 23:21:28 +03:00
freq_norm = pps_normalize_ts ( timespec64_sub ( * raw_ts , pps_fbase ) ) ;
2011-01-13 04:00:56 +03:00
/* check that the signal is in the range
* [ 1 s - MAXFREQ us , 1 s + MAXFREQ us ] , otherwise reject it */
if ( ( freq_norm . sec = = 0 ) | |
( freq_norm . nsec > MAXFREQ * freq_norm . sec ) | |
( freq_norm . nsec < - MAXFREQ * freq_norm . sec ) ) {
time_status | = STA_PPSJITTER ;
/* restart the frequency calibration interval */
pps_fbase = * raw_ts ;
2014-06-05 03:11:43 +04:00
printk_deferred ( KERN_ERR " hardpps: PPSJITTER: bad pulse \n " ) ;
2011-01-13 04:00:56 +03:00
return ;
}
/* signal is ok */
/* check if the current frequency interval is finished */
if ( freq_norm . sec > = ( 1 < < pps_shift ) ) {
pps_calcnt + + ;
/* restart the frequency calibration interval */
pps_fbase = * raw_ts ;
hardpps_update_freq ( freq_norm ) ;
}
hardpps_update_phase ( pts_norm . nsec ) ;
}
# endif /* CONFIG_NTP_PPS */
time: remove obsolete CLOCK_TICK_ADJUST
The first version of the ntp_interval/tick_length inconsistent usage patch was
recently merged as bbe4d18ac2e058c56adb0cd71f49d9ed3216a405
http://git.kernel.org/gitweb.cgi?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=bbe4d18ac2e058c56adb0cd71f49d9ed3216a405
While the fix did greatly improve the situation, it was correctly pointed out
by Roman that it does have a small bug: If the users change clocksources after
the system has been running and NTP has made corrections, the correctoins made
against the old clocksource will be applied against the new clocksource,
causing error.
The second attempt, which corrects the issue in the NTP_INTERVAL_LENGTH
definition has also made it up-stream as commit
e13a2e61dd5152f5499d2003470acf9c838eab84
http://git.kernel.org/gitweb.cgi?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=e13a2e61dd5152f5499d2003470acf9c838eab84
Roman has correctly pointed out that CLOCK_TICK_ADJUST is calculated
based on the PIT's frequency, and isn't really relevant to non-PIT
driven clocksources (that is, clocksources other then jiffies and pit).
This patch reverts both of those changes, and simply removes
CLOCK_TICK_ADJUST.
This does remove the granularity error correction for users of PIT and Jiffies
clocksource users, but the granularity error but for the majority of users, it
should be within the 500ppm range NTP can accommodate for.
For systems that have granularity errors greater then 500ppm, the
"ntp_tick_adj=" boot option can be used to compensate.
[johnstul@us.ibm.com: provided changelog]
[mattilinnanvuori@yahoo.com: maek ntp_tick_adj static]
Signed-off-by: Roman Zippel <zippel@linux-m68k.org>
Acked-by: john stultz <johnstul@us.ibm.com>
Signed-off-by: Matti Linnanvuori <mattilinnanvuori@yahoo.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Cc: mingo@elte.hu
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2008-03-05 02:14:26 +03:00
static int __init ntp_tick_adj_setup ( char * str )
{
2014-05-09 22:32:25 +04:00
int rc = kstrtol ( str , 0 , ( long * ) & ntp_tick_adj ) ;
if ( rc )
return rc ;
2009-02-22 18:03:37 +03:00
ntp_tick_adj < < = NTP_SCALE_SHIFT ;
time: remove obsolete CLOCK_TICK_ADJUST
The first version of the ntp_interval/tick_length inconsistent usage patch was
recently merged as bbe4d18ac2e058c56adb0cd71f49d9ed3216a405
http://git.kernel.org/gitweb.cgi?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=bbe4d18ac2e058c56adb0cd71f49d9ed3216a405
While the fix did greatly improve the situation, it was correctly pointed out
by Roman that it does have a small bug: If the users change clocksources after
the system has been running and NTP has made corrections, the correctoins made
against the old clocksource will be applied against the new clocksource,
causing error.
The second attempt, which corrects the issue in the NTP_INTERVAL_LENGTH
definition has also made it up-stream as commit
e13a2e61dd5152f5499d2003470acf9c838eab84
http://git.kernel.org/gitweb.cgi?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=e13a2e61dd5152f5499d2003470acf9c838eab84
Roman has correctly pointed out that CLOCK_TICK_ADJUST is calculated
based on the PIT's frequency, and isn't really relevant to non-PIT
driven clocksources (that is, clocksources other then jiffies and pit).
This patch reverts both of those changes, and simply removes
CLOCK_TICK_ADJUST.
This does remove the granularity error correction for users of PIT and Jiffies
clocksource users, but the granularity error but for the majority of users, it
should be within the 500ppm range NTP can accommodate for.
For systems that have granularity errors greater then 500ppm, the
"ntp_tick_adj=" boot option can be used to compensate.
[johnstul@us.ibm.com: provided changelog]
[mattilinnanvuori@yahoo.com: maek ntp_tick_adj static]
Signed-off-by: Roman Zippel <zippel@linux-m68k.org>
Acked-by: john stultz <johnstul@us.ibm.com>
Signed-off-by: Matti Linnanvuori <mattilinnanvuori@yahoo.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Cc: mingo@elte.hu
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2008-03-05 02:14:26 +03:00
return 1 ;
}
__setup ( " ntp_tick_adj= " , ntp_tick_adj_setup ) ;
2008-05-01 15:34:41 +04:00
void __init ntp_init ( void )
{
ntp_clear ( ) ;
}