22 Sep, 2016

1 commit


02 Jun, 2016

1 commit

  • In commit 86d3473224b0 some of the checking for a valid timeval
    was subtley changed which caused -EINVAL to be returned whenever
    the timeval was null.

    However, it is possible to set the timezone data while specifying
    a NULL timeval, which is usually done to handle systems where the
    RTC keeps local time instead of UTC. Thus the patch causes such
    systems to have the time incorrectly set.

    This patch addresses the issue by handling the error conditionals
    in the same way as was done previously.

    Fixes: 86d3473224b0 "time: Introduce do_sys_settimeofday64()"
    Reported-by: Mika Westerberg
    Signed-off-by: John Stultz
    Tested-by: Mika Westerberg
    Cc: Prarit Bhargava
    Cc: Arnd Bergmann
    Cc: Baolin Wang
    Cc: Richard Cochran
    Cc: Shuah Khan
    Link: http://lkml.kernel.org/r/1464807207-16530-2-git-send-email-john.stultz@linaro.org
    Signed-off-by: Thomas Gleixner

    John Stultz
     

23 Apr, 2016

1 commit

  • The do_sys_settimeofday() function uses a timespec, which is not year
    2038 safe on 32bit systems.

    Thus this patch introduces do_sys_settimeofday64(), which allows us to
    transition users of do_sys_settimeofday() to using 64bit time types.

    Cc: Prarit Bhargava
    Cc: Richard Cochran
    Cc: Thomas Gleixner
    Cc: Ingo Molnar
    Signed-off-by: Baolin Wang
    [jstultz: Include errno-base.h to avoid build issue on some arches]
    Signed-off-by: John Stultz

    Baolin Wang
     

03 Mar, 2016

3 commits

  • Another representative use case of time sync and the correlated
    clocksource (in addition to PTP noted above) is PTP synchronized
    audio.

    In a streaming application, as an example, samples will be sent and/or
    received by multiple devices with a presentation time that is in terms
    of the PTP master clock. Synchronizing the audio output on these
    devices requires correlating the audio clock with the PTP master
    clock. The more precise this correlation is, the better the audio
    quality (i.e. out of sync audio sounds bad).

    From an application standpoint, to correlate the PTP master clock with
    the audio device clock, the system clock is used as a intermediate
    timebase. The transforms such an application would perform are:

    System Clock Audio clock
    System Clock Network Device Clock [ PTP Master Clock]

    Modern Intel platforms can perform a more accurate cross timestamp in
    hardware (ART,audio device clock). The audio driver requires
    ART->system time transforms -- the same as required for the network
    driver. These platforms offload audio processing (including
    cross-timestamps) to a DSP which to ensure uninterrupted audio
    processing, communicates and response to the host only once every
    millsecond. As a result is takes up to a millisecond for the DSP to
    receive a request, the request is processed by the DSP, the audio
    output hardware is polled for completion, the result is copied into
    shared memory, and the host is notified. All of these operation occur
    on a millisecond cadence. This transaction requires about 2 ms, but
    under heavier workloads it may take up to 4 ms.

    Adding a history allows these slow devices the option of providing an
    ART value outside of the current interval. In this case, the callback
    provided is an accessor function for the previously obtained counter
    value. If get_system_device_crosststamp() receives a counter value
    previous to cycle_last, it consults the history provided as an
    argument in history_ref and interpolates the realtime and monotonic
    raw system time using the provided counter value. If there are any
    clock discontinuities, e.g. from calling settimeofday(), the monotonic
    raw time is interpolated in the usual way, but the realtime clock time
    is adjusted by scaling the monotonic raw adjustment.

    When an accessor function is used a history argument *must* be
    provided. The history is initialized using ktime_get_snapshot() and
    must be called before the counter values are read.

    Cc: Prarit Bhargava
    Cc: Richard Cochran
    Cc: Thomas Gleixner
    Cc: Ingo Molnar
    Cc: Andy Lutomirski
    Cc: kevin.b.stanton@intel.com
    Cc: kevin.j.clarke@intel.com
    Cc: hpa@zytor.com
    Cc: jeffrey.t.kirsher@intel.com
    Cc: netdev@vger.kernel.org
    Reviewed-by: Thomas Gleixner
    Signed-off-by: Christopher S. Hall
    [jstultz: Fixed up cycles_t/cycle_t type confusion]
    Signed-off-by: John Stultz

    Christopher S. Hall
     
  • ACKNOWLEDGMENT: cross timestamp code was developed by Thomas Gleixner
    . It has changed considerably and any mistakes are
    mine.

    The precision with which events on multiple networked systems can be
    synchronized using, as an example, PTP (IEEE 1588, 802.1AS) is limited
    by the precision of the cross timestamps between the system clock and
    the device (timestamp) clock. Precision here is the degree of
    simultaneity when capturing the cross timestamp.

    Currently the PTP cross timestamp is captured in software using the
    PTP device driver ioctl PTP_SYS_OFFSET. Reads of the device clock are
    interleaved with reads of the realtime clock. At best, the precision
    of this cross timestamp is on the order of several microseconds due to
    software latencies. Sub-microsecond precision is required for
    industrial control and some media applications. To achieve this level
    of precision hardware supported cross timestamping is needed.

    The function get_device_system_crosstimestamp() allows device drivers
    to return a cross timestamp with system time properly scaled to
    nanoseconds. The realtime value is needed to discipline that clock
    using PTP and the monotonic raw value is used for applications that
    don't require a "real" time, but need an unadjusted clock time. The
    get_device_system_crosstimestamp() code calls back into the driver to
    ensure that the system counter is within the current timekeeping
    update interval.

    Modern Intel hardware provides an Always Running Timer (ART) which is
    exactly related to TSC through a known frequency ratio. The ART is
    routed to devices on the system and is used to precisely and
    simultaneously capture the device clock with the ART.

    Cc: Prarit Bhargava
    Cc: Richard Cochran
    Cc: Thomas Gleixner
    Cc: Ingo Molnar
    Cc: Andy Lutomirski
    Cc: kevin.b.stanton@intel.com
    Cc: kevin.j.clarke@intel.com
    Cc: hpa@zytor.com
    Cc: jeffrey.t.kirsher@intel.com
    Cc: netdev@vger.kernel.org
    Reviewed-by: Thomas Gleixner
    Signed-off-by: Christopher S. Hall
    [jstultz: Reworked to remove extra structures and simplify calling]
    Signed-off-by: John Stultz

    Christopher S. Hall
     
  • In the current timekeeping code there isn't any interface to
    atomically capture the current relationship between the system counter
    and system time. ktime_get_snapshot() returns this triple (counter,
    monotonic raw, realtime) in the system_time_snapshot struct.

    Cc: Prarit Bhargava
    Cc: Richard Cochran
    Cc: Thomas Gleixner
    Cc: Ingo Molnar
    Cc: Andy Lutomirski
    Cc: kevin.b.stanton@intel.com
    Cc: kevin.j.clarke@intel.com
    Cc: hpa@zytor.com
    Cc: jeffrey.t.kirsher@intel.com
    Cc: netdev@vger.kernel.org
    Reviewed-by: Thomas Gleixner
    Signed-off-by: Christopher S. Hall
    [jstultz: Moved structure definitions around to clean things up,
    fixed cycles_t/cycle_t confusion.]
    Signed-off-by: John Stultz

    Christopher S. Hall
     

02 Oct, 2015

1 commit

  • There is exactly one caller of getnstime_raw_and_real in the kernel,
    which is the pps_get_ts function. This changes the caller and
    the implementation to work on timespec64 types rather than timespec,
    to avoid the time_t overflow on 32-bit architectures.

    For consistency with the other new functions (ktime_get_seconds,
    ktime_get_real_*, ...), I'm renaming the function to
    ktime_get_raw_and_real_ts64.

    We still need to convert from the internal 64-bit type to 32 bit
    types in the caller, but this conversion is now pushed out from
    getnstime_raw_and_real to pps_get_ts. A follow-up patch changes
    the remaining pps code to completely avoid the conversion.

    Acked-by: Richard Cochran
    Acked-by: David S. Miller
    Reviewed-by: Thomas Gleixner
    Signed-off-by: Arnd Bergmann
    Signed-off-by: John Stultz

    Arnd Bergmann
     

21 Aug, 2015

1 commit


18 Aug, 2015

1 commit

  • The current_kernel_time() is not year 2038 safe on 32bit systems
    since it returns a timespec value. Introduce current_kernel_time64()
    which returns a timespec64 value.

    Cc: Prarit Bhargava
    Cc: Richard Cochran
    Cc: Ingo Molnar
    Cc: Thomas Gleixner
    Signed-off-by: Baolin Wang
    Signed-off-by: John Stultz

    Baolin Wang
     

09 Jul, 2015

1 commit


23 May, 2015

2 commits

  • Now that we have a read_boot_clock64() function available on every
    architecture, and converted all the users to it, it's time to remove
    the (now unused) read_boot_clock() completely from the kernel.

    Cc: Thomas Gleixner
    Cc: Ingo Molnar
    Signed-off-by: Xunlei Pang
    [jstultz: Minor commit message tweak suggested by Ingo]
    Signed-off-by: John Stultz

    Xunlei Pang
     
  • This patch series introduces a new function
    u32 ktime_get_resolution_ns(void)
    which allows to clean up some driver code.

    In particular the IIO subsystem has a function to provide timestamps for
    events but no means to get their resolution. So currently the dht11 driver
    tries to guess the resolution in a rather messy and convoluted way. We
    can do much better with the new code.

    This API is not designed to be exposed to user space.

    This has been tested on i386, sunxi and mxs.

    Cc: Thomas Gleixner
    Cc: Ingo Molnar
    Signed-off-by: Harald Geyer
    [jstultz: Tweaked to make it build after upstream changes]
    Signed-off-by: John Stultz

    Harald Geyer
     

03 Apr, 2015

4 commits

  • If a system does not provide a persistent_clock(), the time
    will be updated on resume by rtc_resume(). With the addition
    of the non-stop clocksources for suspend timing, those systems
    set the time on resume in timekeeping_resume(), but may not
    provide a valid persistent_clock().

    This results in the rtc_resume() logic thinking no one has set
    the time and it then will over-write the suspend time again,
    which is not necessary and only increases clock error.

    So, fix this for rtc_resume().

    This patch also improves the name of persistent_clock_exist to
    make it more grammatical.

    Signed-off-by: Xunlei Pang
    Signed-off-by: John Stultz
    Cc: Peter Zijlstra
    Cc: Thomas Gleixner
    Link: http://lkml.kernel.org/r/1427945681-29972-19-git-send-email-john.stultz@linaro.org
    Signed-off-by: Ingo Molnar

    Xunlei Pang
     
  • As part of addressing in-kernel y2038 issues, this patch adds
    update_persistent_clock64() and replaces all the call sites of
    update_persistent_clock() with this function. This is a __weak
    implementation, which simply calls the existing y2038 unsafe
    update_persistent_clock().

    This allows architecture specific implementations to be
    converted independently, and eventually y2038-unsafe
    update_persistent_clock() can be removed after all its
    architecture specific implementations have been converted to
    update_persistent_clock64().

    Suggested-by: Arnd Bergmann
    Signed-off-by: Xunlei Pang
    Signed-off-by: John Stultz
    Cc: Peter Zijlstra
    Cc: Thomas Gleixner
    Link: http://lkml.kernel.org/r/1427945681-29972-4-git-send-email-john.stultz@linaro.org
    Signed-off-by: Ingo Molnar

    Xunlei Pang
     
  • As part of addressing in-kernel y2038 issues, this patch adds
    read_persistent_clock64() and replaces all the call sites of
    read_persistent_clock() with this function. This is a __weak
    implementation, which simply calls the existing y2038 unsafe
    read_persistent_clock().

    This allows architecture specific implementations to be
    converted independently, and eventually the y2038 unsafe
    read_persistent_clock() can be removed after all its
    architecture specific implementations have been converted to
    read_persistent_clock64().

    Suggested-by: Arnd Bergmann
    Signed-off-by: Xunlei Pang
    Signed-off-by: John Stultz
    Cc: Peter Zijlstra
    Cc: Thomas Gleixner
    Link: http://lkml.kernel.org/r/1427945681-29972-3-git-send-email-john.stultz@linaro.org
    Signed-off-by: Ingo Molnar

    Xunlei Pang
     
  • As part of addressing in-kernel y2038 issues, this patch adds
    read_boot_clock64() and replaces all the call sites of
    read_boot_clock() with this function. This is a __weak
    implementation, which simply calls the existing y2038 unsafe
    read_boot_clock().

    This allows architecture specific implementations to be
    converted independently, and eventually the y2038 unsafe
    read_boot_clock() can be removed after all its architecture
    specific implementations have been converted to
    read_boot_clock64().

    Suggested-by: Arnd Bergmann
    Signed-off-by: Xunlei Pang
    Signed-off-by: John Stultz
    Cc: Peter Zijlstra
    Cc: Thomas Gleixner
    Link: http://lkml.kernel.org/r/1427945681-29972-2-git-send-email-john.stultz@linaro.org
    Signed-off-by: Ingo Molnar

    Xunlei Pang
     

27 Mar, 2015

2 commits


24 Jan, 2015

2 commits


11 Dec, 2014

1 commit


22 Nov, 2014

5 commits

  • Since all users have been converted to using the 64bit
    timekeeping_inject_sleeptime64(), remove the old y2038
    problematic timekeeping_inject_sleeptime().

    Signed-off-by: John Stultz

    John Stultz
     
  • Adds a timespec64 based get_monotonic_coarse64() implementation
    that can be used as we convert internal users of
    get_monotonic_coarse away from using timespecs.

    Signed-off-by: John Stultz

    John Stultz
     
  • Adds a timespec64 based getrawmonotonic64() implementation
    that can be used as we convert internal users of
    getrawmonotonic away from using timespecs.

    Signed-off-by: John Stultz

    John Stultz
     
  • As part of addressing "y2038 problem" for in-kernel uses, this
    patch adds timekeeping_inject_sleeptime64() using timespec64.

    After this patch, timekeeping_inject_sleeptime() is deprecated
    and all its call sites will be fixed using the new interface,
    after that it can be removed.

    NOTE: timekeeping_inject_sleeptime() is safe actually, but we
    want to eliminate timespec eventually, so comes this patch.

    Signed-off-by: pang.xunlei
    Signed-off-by: John Stultz

    pang.xunlei
     
  • The kernel uses 32-bit signed value(time_t) for seconds elapsed
    1970-01-01:00:00:00, thus it will overflow at 2038-01-19 03:14:08
    on 32-bit systems. This is widely known as the y2038 problem.

    As part of addressing "y2038 problem" for in-kernel uses, this patch
    adds safe do_settimeofday64() using timespec64.

    After this patch, do_settimeofday() is deprecated and all its call
    sites will be fixed using do_settimeofday64(), after that it can be
    removed.

    Signed-off-by: pang.xunlei
    Signed-off-by: John Stultz

    pang.xunlei
     

29 Oct, 2014

2 commits

  • ktime_get_real_seconds() is the replacement function for get_seconds()
    returning the seconds portion of CLOCK_REALTIME in a time64_t. For
    64bit the function is equivivalent to get_seconds(), but for 32bit it
    protects the readout with the timekeeper sequence count. This is
    required because 32-bit machines cannot access 64-bit tk->xtime_sec
    variable atomically.

    [tglx: Massaged changelog and added docbook comment ]

    Signed-off-by: Heena Sirwani
    Reviewed-by: Arnd Bergman
    Cc: John Stultz
    Cc: opw-kernel@googlegroups.com
    Link: http://lkml.kernel.org/r/7adcfaa8962b8ad58785d9a2456c3f77d93c0ffb.1414578445.git.heenasirwani@gmail.com
    Signed-off-by: Thomas Gleixner

    Heena Sirwani
     
  • This is the counterpart to get_seconds() based on CLOCK_MONOTONIC. The
    use case for this interface are kernel internal coarse grained
    timestamps which do neither require the nanoseconds fraction of
    current time nor the CLOCK_REALTIME properties. Such timestamps can
    currently only retrieved by calling ktime_get_ts64() and using the
    tv_sec field of the returned timespec64. That's inefficient as it
    involves the read of the clocksource, math operations and must be
    protected by the timekeeper sequence counter.

    To avoid the sequence counter protection we restrict the return value
    to unsigned 32bit on 32bit machines. This covers ~136 years of uptime
    and therefor an overflow is not expected to hit anytime soon.

    To avoid math in the function we calculate the current seconds portion
    of CLOCK_MONOTONIC when the timekeeper gets updated in
    tk_update_ktime_data() similar to the CLOCK_REALTIME counterpart
    xtime_sec.

    [ tglx: Massaged changelog, simplified and commented the update
    function, added docbook comment ]

    Signed-off-by: Heena Sirwani
    Reviewed-by: Arnd Bergman
    Cc: John Stultz
    Cc: opw-kernel@googlegroups.com
    Link: http://lkml.kernel.org/r/da0b63f4bdf3478909f92becb35861197da3a905.1414578445.git.heenasirwani@gmail.com
    Signed-off-by: Thomas Gleixner

    Heena Sirwani
     

24 Jul, 2014

12 commits