1. 02 11月, 2017 2 次提交
  2. 31 10月, 2017 5 次提交
    • A
      time: Move time_t conversion helpers to time32.h · abc8f96e
      Arnd Bergmann 提交于
      On 64-bit architectures, the timespec64 based helpers in linux/time.h
      are defined as macros pointing to their timespec based counterparts.
      This made sense when they were first introduced, but as we are migrating
      away from timespec in general, it's much less intuitive now.
      
      This changes the macros to work in the exact opposite way: we always
      provide the timespec64 based helpers and define the old interfaces as
      macros for them. Now we can move those macros into linux/time32.h, which
      already contains the respective helpers for 32-bit architectures.
      
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Miroslav Lichvar <mlichvar@redhat.com>
      Cc: Richard Cochran <richardcochran@gmail.com>
      Cc: Prarit Bhargava <prarit@redhat.com>
      Cc: Stephen Boyd <stephen.boyd@linaro.org>
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NJohn Stultz <john.stultz@linaro.org>
      abc8f96e
    • A
      time: Remove unused functions · 85bf19e7
      Arnd Bergmann 提交于
      The (slow but) ongoing work on conversion from timespec to timespec64
      has led some timespec based helper functions to become unused.
      
      No new code should use them, so we can remove the functions entirely.
      I'm planning to obsolete additional interfaces next and remove
      more of these.
      
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Miroslav Lichvar <mlichvar@redhat.com>
      Cc: Richard Cochran <richardcochran@gmail.com>
      Cc: Prarit Bhargava <prarit@redhat.com>
      Cc: Stephen Boyd <stephen.boyd@linaro.org>
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NJohn Stultz <john.stultz@linaro.org>
      85bf19e7
    • A
      timekeeping: Use timespec64 in timekeeping_inject_offset · 1572fa03
      Arnd Bergmann 提交于
      As part of changing all the timekeeping code to use 64-bit
      time_t consistently, this removes the uses of timeval
      and timespec as much as possible from do_adjtimex() and
      timekeeping_inject_offset(). The timeval_inject_offset_valid()
      and timespec_inject_offset_valid() just complicate this,
      so I'm folding them into the respective callers.
      
      This leaves the actual 'struct timex' definition, which
      is part of the user-space ABI and should be dealt with
      separately when we have agreed on the ABI change.
      
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Miroslav Lichvar <mlichvar@redhat.com>
      Cc: Richard Cochran <richardcochran@gmail.com>
      Cc: Prarit Bhargava <prarit@redhat.com>
      Cc: Stephen Boyd <stephen.boyd@linaro.org>
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NJohn Stultz <john.stultz@linaro.org>
      1572fa03
    • A
      timekeeping: Consolidate timekeeping_inject_offset code · e0956dcc
      Arnd Bergmann 提交于
      The code to check the adjtimex() or clock_adjtime() arguments is spread
      out across multiple files for presumably only historic reasons. As a
      preparatation for a rework to get rid of the use of 'struct timeval'
      and 'struct timespec' in there, this moves all the portions into
      kernel/time/timekeeping.c and marks them as 'static'.
      
      The warp_clock() function here is not as closely related as the others,
      but I feel it still makes sense to move it here in order to consolidate
      all callers of timekeeping_inject_offset().
      
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Miroslav Lichvar <mlichvar@redhat.com>
      Cc: Richard Cochran <richardcochran@gmail.com>
      Cc: Prarit Bhargava <prarit@redhat.com>
      Cc: Stephen Boyd <stephen.boyd@linaro.org>
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      [jstultz: Whitespace fixup]
      Signed-off-by: NJohn Stultz <john.stultz@linaro.org>
      e0956dcc
    • J
      rtc: Allow rtc drivers to specify the tv_nsec value for ntp · 0f295b06
      Jason Gunthorpe 提交于
      ntp is currently hardwired to try and call the rtc set when wall clock
      tv_nsec is 0.5 seconds. This historical behaviour works well with certain
      PC RTCs, but is not universal to all rtc hardware.
      
      Change how this works by introducing the driver specific concept of
      set_offset_nsec, the delay between current wall clock time and the target
      time to set (with a 0 tv_nsecs).
      
      For x86-style CMOS set_offset_nsec should be -0.5 s which causes the last
      second to be written 0.5 s after it has started.
      
      For compat with the old rtc_set_ntp_time, the value is defaulted to
      + 0.5 s, which causes the next second to be written 0.5s before it starts,
      as things were before this patch.
      
      Testing shows many non-x86 RTCs would like set_offset_nsec ~= 0,
      so ultimately each RTC driver should set the set_offset_nsec according
      to its needs, and non x86 architectures should stop using
      update_persistent_clock64 in order to access this feature.
      Future patches will revise the drivers as needed.
      
      Since CMOS and RTC now have very different handling they are split
      into two dedicated code paths, sharing the support code, and ifdefs
      are replaced with IS_ENABLED.
      
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Miroslav Lichvar <mlichvar@redhat.com>
      Cc: Richard Cochran <richardcochran@gmail.com>
      Cc: Prarit Bhargava <prarit@redhat.com>
      Cc: Stephen Boyd <stephen.boyd@linaro.org>
      Signed-off-by: NJason Gunthorpe <jgunthorpe@obsidianresearch.com>
      Signed-off-by: NJohn Stultz <john.stultz@linaro.org>
      0f295b06
  3. 19 10月, 2017 1 次提交
    • J
      clockevents: Retry programming min delta up to 10 times · 3a29ddb1
      James Hogan 提交于
      When CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=n, the call path
      hrtimer_reprogram -> clockevents_program_event ->
      clockevents_program_min_delta will not retry if the clock event driver
      returns -ETIME.
      
      If the driver could not satisfy the program_min_delta for any reason, the
      lack of a retry means the CPU may not receive a tick interrupt, potentially
      until the counter does a full period. This leads to rcu_sched timeout
      messages as the stalled CPU is detected by other CPUs, and other issues if
      the CPU is holding locks or other resources at the point at which it
      stalls.
      
      There have been a couple of observed mechanisms through which a clock event
      driver could not satisfy the requested min_delta and return -ETIME.
      
      With the MIPS GIC driver, the shared execution resource within MT cores
      means inconventient latency due to execution of instructions from other
      hardware threads in the core, within gic_next_event, can result in an event
      being set in the past.
      
      Additionally under virtualisation it is possible to get unexpected latency
      during a clockevent device's set_next_event() callback which can make it
      return -ETIME even for a delta based on min_delta_ns.
      
      It isn't appropriate to use MIN_ADJUST in the virtualisation case as
      occasional hypervisor induced high latency will cause min_delta_ns to
      quickly increase to the maximum.
      
      Instead, borrow the retry pattern from the MIN_ADJUST case, but without
      making adjustments. Retry up to 10 times, each time increasing the
      attempted delta by min_delta, before giving up.
      
      [ Matt: Reworked the loop and made retry increase the delta. ]
      Signed-off-by: NJames Hogan <jhogan@kernel.org>
      Signed-off-by: NMatt Redfearn <matt.redfearn@mips.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: linux-mips@linux-mips.org
      Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
      Cc: "Martin Schwidefsky" <schwidefsky@de.ibm.com>
      Cc: James Hogan <james.hogan@mips.com>
      Link: https://lkml.kernel.org/r/1508422643-6075-1-git-send-email-matt.redfearn@mips.com
      3a29ddb1
  4. 18 10月, 2017 2 次提交
  5. 17 10月, 2017 2 次提交
  6. 05 10月, 2017 1 次提交
    • K
      timer: Convert schedule_timeout() to use from_timer() · 58e1177b
      Kees Cook 提交于
      In preparation for unconditionally passing the struct timer_list pointer to
      all timer callbacks, switch to using the new from_timer() helper and passing
      the timer pointer explicitly. Since this special timer is on the stack, it
      needs to have a wrapper structure to carry state once .data is eliminated.
      Signed-off-by: NKees Cook <keescook@chromium.org>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: linux-mips@linux-mips.org
      Cc: Petr Mladek <pmladek@suse.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Lai Jiangshan <jiangshanlai@gmail.com>
      Cc: Sebastian Reichel <sre@kernel.org>
      Cc: Kalle Valo <kvalo@qca.qualcomm.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Pavel Machek <pavel@ucw.cz>
      Cc: linux1394-devel@lists.sourceforge.net
      Cc: Chris Metcalf <cmetcalf@mellanox.com>
      Cc: linux-s390@vger.kernel.org
      Cc: linux-wireless@vger.kernel.org
      Cc: "James E.J. Bottomley" <jejb@linux.vnet.ibm.com>
      Cc: Wim Van Sebroeck <wim@iguana.be>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Ursula Braun <ubraun@linux.vnet.ibm.com>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Cc: Viresh Kumar <viresh.kumar@linaro.org>
      Cc: Harish Patil <harish.patil@cavium.com>
      Cc: Guenter Roeck <linux@roeck-us.net>
      Cc: Manish Chopra <manish.chopra@cavium.com>
      Cc: Len Brown <len.brown@intel.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: linux-pm@vger.kernel.org
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Julian Wiedmann <jwi@linux.vnet.ibm.com>
      Cc: John Stultz <john.stultz@linaro.org>
      Cc: Mark Gross <mark.gross@intel.com>
      Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
      Cc: linux-watchdog@vger.kernel.org
      Cc: linux-scsi@vger.kernel.org
      Cc: "Martin K. Petersen" <martin.petersen@oracle.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Stephen Boyd <sboyd@codeaurora.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Stefan Richter <stefanr@s5r6.in-berlin.de>
      Cc: Michael Reed <mdr@sgi.com>
      Cc: netdev@vger.kernel.org
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: linuxppc-dev@lists.ozlabs.org
      Cc: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
      Link: https://lkml.kernel.org/r/1507159627-127660-2-git-send-email-keescook@chromium.org
      58e1177b
  7. 26 9月, 2017 2 次提交
  8. 09 9月, 2017 1 次提交
  9. 01 9月, 2017 1 次提交
  10. 26 8月, 2017 1 次提交
    • J
      time: Fix ktime_get_raw() incorrect base accumulation · 0bcdc098
      John Stultz 提交于
      In comqit fc6eead7 ("time: Clean up CLOCK_MONOTONIC_RAW time
      handling"), the following code got mistakenly added to the update of the
      raw timekeeper:
      
       /* Update the monotonic raw base */
       seconds = tk->raw_sec;
       nsec = (u32)(tk->tkr_raw.xtime_nsec >> tk->tkr_raw.shift);
       tk->tkr_raw.base = ns_to_ktime(seconds * NSEC_PER_SEC + nsec);
      
      Which adds the raw_sec value and the shifted down raw xtime_nsec to the
      base value.
      
      But the read function adds the shifted down tk->tkr_raw.xtime_nsec value
      another time, The result of this is that ktime_get_raw() users (which are
      all internal users) see the raw time move faster then it should (the rate
      at which can vary with the current size of tkr_raw.xtime_nsec), which has
      resulted in at least problems with graphics rendering performance.
      
      The change tried to match the monotonic base update logic:
      
       seconds = (u64)(tk->xtime_sec + tk->wall_to_monotonic.tv_sec);
       nsec = (u32) tk->wall_to_monotonic.tv_nsec;
       tk->tkr_mono.base = ns_to_ktime(seconds * NSEC_PER_SEC + nsec);
      
      Which adds the wall_to_monotonic.tv_nsec value, but not the
      tk->tkr_mono.xtime_nsec value to the base.
      
      To fix this, simplify the tkr_raw.base accumulation to only accumulate the
      raw_sec portion, and do not include the tkr_raw.xtime_nsec portion, which
      will be added at read time.
      
      Fixes: fc6eead7 ("time: Clean up CLOCK_MONOTONIC_RAW time handling")
      Reported-and-tested-by: NChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NJohn Stultz <john.stultz@linaro.org>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Prarit Bhargava <prarit@redhat.com>
      Cc: Kevin Brodsky <kevin.brodsky@arm.com>
      Cc: Richard Cochran <richardcochran@gmail.com>
      Cc: Stephen Boyd <stephen.boyd@linaro.org>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Miroslav Lichvar <mlichvar@redhat.com>
      Cc: Daniel Mentz <danielmentz@google.com>
      Link: http://lkml.kernel.org/r/1503701824-1645-1-git-send-email-john.stultz@linaro.org
      0bcdc098
  11. 24 8月, 2017 1 次提交
    • N
      timers: Fix excessive granularity of new timers after a nohz idle · 2fe59f50
      Nicholas Piggin 提交于
      When a timer base is idle, it is forwarded when a new timer is added
      to ensure that granularity does not become excessive. When not idle,
      the timer tick is expected to increment the base.
      
      However there are several problems:
      
      - If an existing timer is modified, the base is forwarded only after
        the index is calculated.
      
      - The base is not forwarded by add_timer_on.
      
      - There is a window after a timer is restarted from a nohz idle, after
        it is marked not-idle and before the timer tick on this CPU, where a
        timer may be added but the ancient base does not get forwarded.
      
      These result in excessive granularity (a 1 jiffy timeout can blow out
      to 100s of jiffies), which cause the rcu lockup detector to trigger,
      among other things.
      
      Fix this by keeping track of whether the timer base has been idle
      since it was last run or forwarded, and if so then forward it before
      adding a new timer.
      
      There is still a case where mod_timer optimises the case of a pending
      timer mod with the same expiry time, where the timer can see excessive
      granularity relative to the new, shorter interval. A comment is added,
      but it's not changed because it is an important fastpath for
      networking.
      
      This has been tested and found to fix the RCU softlockup messages.
      
      Testing was also done with tracing to measure requested versus
      achieved wakeup latencies for all non-deferrable timers in an idle
      system (with no lockup watchdogs running). Wakeup latency relative to
      absolute latency is calculated (note this suffers from round-up skew
      at low absolute times) and analysed:
      
                   max     avg      std
      upstream   506.0    1.20     4.68
      patched      2.0    1.08     0.15
      
      The bug was noticed due to the lockup detector Kconfig changes
      dropping it out of people's .configs and resulting in larger base
      clk skew When the lockup detectors are enabled, no CPU can go idle for
      longer than 4 seconds, which limits the granularity errors.
      Sub-optimal timer behaviour is observable on a smaller scale in that
      case:
      
      	     max     avg      std
      upstream     9.0    1.05     0.19
      patched      2.0    1.04     0.11
      
      Fixes: Fixes: a683f390 ("timers: Forward the wheel clock whenever possible")
      Signed-off-by: NNicholas Piggin <npiggin@gmail.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Tested-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
      Tested-by: NDavid Miller <davem@davemloft.net>
      Cc: dzickus@redhat.com
      Cc: sfr@canb.auug.org.au
      Cc: mpe@ellerman.id.au
      Cc: Stephen Boyd <sboyd@codeaurora.org>
      Cc: linuxarm@huawei.com
      Cc: abdhalee@linux.vnet.ibm.com
      Cc: John Stultz <john.stultz@linaro.org>
      Cc: akpm@linux-foundation.org
      Cc: paulmck@linux.vnet.ibm.com
      Cc: torvalds@linux-foundation.org
      Cc: stable@vger.kernel.org
      Link: http://lkml.kernel.org/r/20170822084348.21436-1-npiggin@gmail.com
      2fe59f50
  12. 18 8月, 2017 3 次提交
  13. 01 8月, 2017 1 次提交
  14. 23 7月, 2017 1 次提交
    • R
      PM / timekeeping: Print debug messages when requested · cb08e035
      Rafael J. Wysocki 提交于
      The messages printed by tk_debug_account_sleep_time() are basically
      useful for system sleep debugging, so print them only when the other
      debug messages from the core suspend/hibernate code are enabled.
      
      While at it, make it clear that the messages from
      tk_debug_account_sleep_time() are about timekeeping suspend
      duration, because in general timekeeping may be suspeded and
      resumed for multiple times during one system suspend-resume cycle.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      cb08e035
  15. 30 6月, 2017 3 次提交
  16. 29 6月, 2017 1 次提交
  17. 26 6月, 2017 3 次提交
  18. 22 6月, 2017 2 次提交
  19. 21 6月, 2017 5 次提交
  20. 20 6月, 2017 2 次提交
    • J
      time: Fix CLOCK_MONOTONIC_RAW sub-nanosecond accounting · 3d88d56c
      John Stultz 提交于
      Due to how the MONOTONIC_RAW accumulation logic was handled,
      there is the potential for a 1ns discontinuity when we do
      accumulations. This small discontinuity has for the most part
      gone un-noticed, but since ARM64 enabled CLOCK_MONOTONIC_RAW
      in their vDSO clock_gettime implementation, we've seen failures
      with the inconsistency-check test in kselftest.
      
      This patch addresses the issue by using the same sub-ns
      accumulation handling that CLOCK_MONOTONIC uses, which avoids
      the issue for in-kernel users.
      
      Since the ARM64 vDSO implementation has its own clock_gettime
      calculation logic, this patch reduces the frequency of errors,
      but failures are still seen. The ARM64 vDSO will need to be
      updated to include the sub-nanosecond xtime_nsec values in its
      calculation for this issue to be completely fixed.
      Signed-off-by: NJohn Stultz <john.stultz@linaro.org>
      Tested-by: NDaniel Mentz <danielmentz@google.com>
      Cc: Prarit Bhargava <prarit@redhat.com>
      Cc: Kevin Brodsky <kevin.brodsky@arm.com>
      Cc: Richard Cochran <richardcochran@gmail.com>
      Cc: Stephen Boyd <stephen.boyd@linaro.org>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: "stable #4 . 8+" <stable@vger.kernel.org>
      Cc: Miroslav Lichvar <mlichvar@redhat.com>
      Link: http://lkml.kernel.org/r/1496965462-20003-3-git-send-email-john.stultz@linaro.orgSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      3d88d56c
    • J
      time: Fix clock->read(clock) race around clocksource changes · ceea5e37
      John Stultz 提交于
      In tests, which excercise switching of clocksources, a NULL
      pointer dereference can be observed on AMR64 platforms in the
      clocksource read() function:
      
      u64 clocksource_mmio_readl_down(struct clocksource *c)
      {
      	return ~(u64)readl_relaxed(to_mmio_clksrc(c)->reg) & c->mask;
      }
      
      This is called from the core timekeeping code via:
      
      	cycle_now = tkr->read(tkr->clock);
      
      tkr->read is the cached tkr->clock->read() function pointer.
      When the clocksource is changed then tkr->clock and tkr->read
      are updated sequentially. The code above results in a sequential
      load operation of tkr->read and tkr->clock as well.
      
      If the store to tkr->clock hits between the loads of tkr->read
      and tkr->clock, then the old read() function is called with the
      new clock pointer. As a consequence the read() function
      dereferences a different data structure and the resulting 'reg'
      pointer can point anywhere including NULL.
      
      This problem was introduced when the timekeeping code was
      switched over to use struct tk_read_base. Before that, it was
      theoretically possible as well when the compiler decided to
      reload clock in the code sequence:
      
           now = tk->clock->read(tk->clock);
      
      Add a helper function which avoids the issue by reading
      tk_read_base->clock once into a local variable clk and then issue
      the read function via clk->read(clk). This guarantees that the
      read() function always gets the proper clocksource pointer handed
      in.
      
      Since there is now no use for the tkr.read pointer, this patch
      also removes it, and to address stopping the fast timekeeper
      during suspend/resume, it introduces a dummy clocksource to use
      rather then just a dummy read function.
      Signed-off-by: NJohn Stultz <john.stultz@linaro.org>
      Acked-by: NIngo Molnar <mingo@kernel.org>
      Cc: Prarit Bhargava <prarit@redhat.com>
      Cc: Richard Cochran <richardcochran@gmail.com>
      Cc: Stephen Boyd <stephen.boyd@linaro.org>
      Cc: stable <stable@vger.kernel.org>
      Cc: Miroslav Lichvar <mlichvar@redhat.com>
      Cc: Daniel Mentz <danielmentz@google.com>
      Link: http://lkml.kernel.org/r/1496965462-20003-2-git-send-email-john.stultz@linaro.orgSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      ceea5e37