1. 13 9月, 2012 1 次提交
  2. 02 9月, 2012 1 次提交
    • J
      time: Move ktime_t overflow checking into timespec_valid_strict · cee58483
      John Stultz 提交于
      Andreas Bombe reported that the added ktime_t overflow checking added to
      timespec_valid in commit 4e8b1452 ("time: Improve sanity checking of
      timekeeping inputs") was causing problems with X.org because it caused
      timeouts larger then KTIME_T to be invalid.
      
      Previously, these large timeouts would be clamped to KTIME_MAX and would
      never expire, which is valid.
      
      This patch splits the ktime_t overflow checking into a new
      timespec_valid_strict function, and converts the timekeeping codes
      internal checking to use this more strict function.
      Reported-and-tested-by: NAndreas Bombe <aeb@debian.org>
      Cc: Zhouping Liu <zliu@redhat.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Prarit Bhargava <prarit@redhat.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: stable@vger.kernel.org
      Signed-off-by: NJohn Stultz <john.stultz@linaro.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      cee58483
  3. 22 8月, 2012 4 次提交
  4. 15 8月, 2012 1 次提交
  5. 05 8月, 2012 1 次提交
    • I
      time: Fix adjustment cleanup bug in timekeeping_adjust() · 1d17d174
      Ingo Molnar 提交于
      Tetsuo Handa reported that sporadically the system clock starts
      counting up too quickly which is enough to confuse the hangcheck
      timer to print a bogus stall warning.
      
      Commit 2a8c0883 "time: Move xtime_nsec adjustment underflow handling
      timekeeping_adjust" overlooked this exit path:
      
              } else
                      return;
      
      which should really be a proper exit sequence, fixing the bug as a
      side effect.
      
      Also make the flow more readable by properly balancing curly
      braces.
      
      Reported-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> wrote:
      Tested-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> wrote:
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      Cc: john.stultz@linaro.org
      Cc: a.p.zijlstra@chello.nl
      Cc: richardcochran@gmail.com
      Cc: prarit@redhat.com
      Link: http://lkml.kernel.org/r/20120804192114.GA28347@gmail.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      1d17d174
  6. 31 7月, 2012 3 次提交
  7. 24 7月, 2012 1 次提交
  8. 17 7月, 2012 1 次提交
  9. 15 7月, 2012 7 次提交
  10. 12 7月, 2012 3 次提交
  11. 05 6月, 2012 1 次提交
  12. 22 5月, 2012 1 次提交
  13. 24 3月, 2012 2 次提交
  14. 23 3月, 2012 1 次提交
    • J
      ntp: Fix leap-second hrtimer livelock · 6b43ae8a
      John Stultz 提交于
      Since commit 7dffa3c6 the ntp
      subsystem has used an hrtimer for triggering the leapsecond
      adjustment. However, this can cause a potential livelock.
      
      Thomas diagnosed this as the following pattern:
      CPU 0                                                    CPU 1
      do_adjtimex()
        spin_lock_irq(&ntp_lock);
          process_adjtimex_modes();				 timer_interrupt()
            process_adj_status();                                do_timer()
              ntp_start_leap_timer();                             write_lock(&xtime_lock);
                hrtimer_start();                                  update_wall_time();
                   hrtimer_reprogram();                            ntp_tick_length()
                     tick_program_event()                            spin_lock(&ntp_lock);
                       clockevents_program_event()
      		   ktime_get()
                           seq = req_seqbegin(xtime_lock);
      
      This patch tries to avoid the problem by reverting back to not using
      an hrtimer to inject leapseconds, and instead we handle the leapsecond
      processing in the second_overflow() function.
      
      The downside to this change is that on systems that support highres
      timers, the leap second processing will occur on a HZ tick boundary,
      (ie: ~1-10ms, depending on HZ)  after the leap second instead of
      possibly sooner (~34us in my tests w/ x86_64 lapic).
      
      This patch applies on top of tip/timers/core.
      
      CC: Sasha Levin <levinsasha928@gmail.com>
      CC: Thomas Gleixner <tglx@linutronix.de>
      Reported-by: NSasha Levin <levinsasha928@gmail.com>
      Diagnoised-by: NThomas Gleixner <tglx@linutronix.de>
      Tested-by: NSasha Levin <levinsasha928@gmail.com>
      Signed-off-by: NJohn Stultz <john.stultz@linaro.org>
      6b43ae8a
  15. 16 3月, 2012 1 次提交
    • J
      time: Fix change_clocksource locking · f695cf94
      John Stultz 提交于
      change_clocksource() fails to grab locks or call timekeeping_update(),
      which leaves a race window for time inconsistencies.
      
      This adds proper locking and a call to timekeeping_update() to fix this.
      
      CC: Andy Lutomirski <luto@amacapital.net>
      CC: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NJohn Stultz <john.stultz@linaro.org>
      f695cf94
  16. 03 2月, 2012 1 次提交
    • J
      Input: add infrastructure for selecting clockid for event time stamps · a80b83b7
      John Stultz 提交于
      As noted by Arve and others, since wall time can jump backwards, it is
      difficult to use for input because one cannot determine if one event
      occurred before another or for how long a key was pressed.
      
      However, the timestamp field is part of the kernel ABI, and cannot be
      changed without possibly breaking existing users.
      
      This patch adds a new IOCTL that allows a clockid to be set in the
      evdev_client struct that will specify which time base to use for event
      timestamps (ie: CLOCK_MONOTONIC instead of CLOCK_REALTIME).
      
      For now we only support CLOCK_MONOTONIC and CLOCK_REALTIME, but
      in the future we could support other clockids if appropriate.
      
      The default remains CLOCK_REALTIME, so we don't change the ABI.
      Signed-off-by: NJohn Stultz <john.stultz@linaro.org>
      Reviewed-by: NDaniel Kurtz <djkurtz@google.com>
      Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
      a80b83b7
  17. 27 1月, 2012 10 次提交