1. 12 9月, 2013 1 次提交
    • J
      timekeeping: Fix HRTICK related deadlock from ntp lock changes · 7bd36014
      John Stultz 提交于
      Gerlando Falauto reported that when HRTICK is enabled, it is
      possible to trigger system deadlocks. These were hard to
      reproduce, as HRTICK has been broken in the past, but seemed
      to be connected to the timekeeping_seq lock.
      
      Since seqlock/seqcount's aren't supported w/ lockdep, I added
      some extra spinlock based locking and triggered the following
      lockdep output:
      
      [   15.849182] ntpd/4062 is trying to acquire lock:
      [   15.849765]  (&(&pool->lock)->rlock){..-...}, at: [<ffffffff810aa9b5>] __queue_work+0x145/0x480
      [   15.850051]
      [   15.850051] but task is already holding lock:
      [   15.850051]  (timekeeper_lock){-.-.-.}, at: [<ffffffff810df6df>] do_adjtimex+0x7f/0x100
      
      <snip>
      
      [   15.850051] Chain exists of: &(&pool->lock)->rlock --> &p->pi_lock --> timekeeper_lock
      [   15.850051]  Possible unsafe locking scenario:
      [   15.850051]
      [   15.850051]        CPU0                    CPU1
      [   15.850051]        ----                    ----
      [   15.850051]   lock(timekeeper_lock);
      [   15.850051]                                lock(&p->pi_lock);
      [   15.850051] lock(timekeeper_lock);
      [   15.850051] lock(&(&pool->lock)->rlock);
      [   15.850051]
      [   15.850051]  *** DEADLOCK ***
      
      The deadlock was introduced by 06c017fd ("timekeeping:
      Hold timekeepering locks in do_adjtimex and hardpps") in 3.10
      
      This patch avoids this deadlock, by moving the call to
      schedule_delayed_work() outside of the timekeeper lock
      critical section.
      Reported-by: NGerlando Falauto <gerlando.falauto@keymile.com>
      Tested-by: NLin Ming <minggr@gmail.com>
      Signed-off-by: NJohn Stultz <john.stultz@linaro.org>
      Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
      Cc: stable <stable@vger.kernel.org> #3.11, 3.10
      Link: http://lkml.kernel.org/r/1378943457-27314-1-git-send-email-john.stultz@linaro.orgSigned-off-by: NIngo Molnar <mingo@kernel.org>
      7bd36014
  2. 23 8月, 2013 1 次提交
    • M
      ntp: Make periodic RTC update more reliable · a97ad0c4
      Miroslav Lichvar 提交于
      The current code requires that the scheduled update of the RTC happens
      in the closest tick to the half of the second. This seems to be
      difficult to achieve reliably. The scheduled work may be missing the
      target time by a tick or two and be constantly rescheduled every second.
      
      Relax the limit to 10 ticks. As a typical RTC drifts in the 11-minute
      update interval by several milliseconds, this shouldn't affect the
      overall accuracy of the RTC much.
      Signed-off-by: NMiroslav Lichvar <mlichvar@redhat.com>
      Signed-off-by: NJohn Stultz <john.stultz@linaro.org>
      a97ad0c4
  3. 29 5月, 2013 1 次提交
  4. 05 4月, 2013 6 次提交
  5. 23 3月, 2013 1 次提交
  6. 19 2月, 2013 1 次提交
  7. 09 2月, 2013 1 次提交
    • P
      time, Fix setting of hardware clock in NTP code · 84e345e4
      Prarit Bhargava 提交于
      At init time, if the system time is "warped" forward in warp_clock()
      it will differ from the hardware clock by sys_tz.tz_minuteswest.  This time
      difference is not taken into account when ntp updates the hardware clock,
      and this causes the system time to jump forward by this offset every reboot.
      
      The kernel must take this offset into account when writing the system time
      to the hardware clock in the ntp code.  This patch adds
      persistent_clock_is_local which indicates that an offset has been applied
      in warp_clock() and accounts for the "warp" before writing the hardware
      clock.
      
      x86 does not have this problem as rtc writes are software limited to a
      +/-15 minute window relative to the current rtc time.  Other arches, such
      as powerpc, however do a full synchronization of the system time to the
      rtc and will see this problem.
      
      [v2]: generated against tip/timers/core
      Signed-off-by: NPrarit Bhargava <prarit@redhat.com>
      Cc: John Stultz <john.stultz@linaro.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NJohn Stultz <john.stultz@linaro.org>
      84e345e4
  8. 16 1月, 2013 1 次提交
    • J
      NTP: Add a CONFIG_RTC_SYSTOHC configuration · 023f333a
      Jason Gunthorpe 提交于
      The purpose of this option is to allow ARM/etc systems that rely on the
      class RTC subsystem to have the same kind of automatic NTP based
      synchronization that we have on PC platforms. Today ARM does not
      implement update_persistent_clock and makes extensive use of the class
      RTC system.
      
      When enabled CONFIG_RTC_SYSTOHC will provide a generic
      rtc_update_persistent_clock that stores the current time in the RTC and
      is intended complement the existing CONFIG_RTC_HCTOSYS option that loads
      the RTC at boot.
      
      Like with RTC_HCTOSYS the platform's update_persistent_clock is used
      first, if it works. Platforms with mixed class RTC and non-RTC drivers
      need to return ENODEV when class RTC should be used. Such an update for
      PPC is included in this patch.
      
      Long term, implementations of update_persistent_clock should migrate to
      proper class RTC drivers and use CONFIG_RTC_SYSTOHC instead.
      
      Tested on ARM kirkwood and PPC405
      Signed-off-by: NJason Gunthorpe <jgunthorpe@obsidianresearch.com>
      Signed-off-by: NJohn Stultz <john.stultz@linaro.org>
      023f333a
  9. 31 7月, 2012 1 次提交
  10. 15 7月, 2012 1 次提交
  11. 22 5月, 2012 2 次提交
  12. 24 3月, 2012 1 次提交
  13. 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
  14. 16 3月, 2012 1 次提交
  15. 27 1月, 2012 3 次提交
  16. 04 4月, 2011 1 次提交
  17. 19 2月, 2011 1 次提交
  18. 02 2月, 2011 1 次提交
  19. 01 2月, 2011 1 次提交
  20. 14 1月, 2011 1 次提交
    • A
      ntp: add hardpps implementation · 025b40ab
      Alexander Gordeev 提交于
      This commit adds hardpps() implementation based upon the original one from
      the NTPv4 reference kernel code from David Mills.  However, it is highly
      optimized towards very fast syncronization and maximum stickness to PPS
      signal.  The typical error is less then a microsecond.
      
      To make it sync faster I had to throw away exponential phase filter so
      that the full phase offset is corrected immediately.  Then I also had to
      throw away median phase filter because it gives a bigger error itself if
      used without exponential filter.
      
      Maybe we will find an appropriate filtering scheme in the future but it's
      not necessary if the signal quality is ok.
      Signed-off-by: NAlexander Gordeev <lasaine@lvk.cs.msu.su>
      Acked-by: NJohn Stultz <johnstul@us.ibm.com>
      Cc: Rodolfo Giometti <giometti@enneenne.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      025b40ab
  21. 10 9月, 2010 1 次提交
  22. 24 3月, 2010 1 次提交
  23. 29 1月, 2010 2 次提交
  24. 15 8月, 2009 1 次提交
  25. 27 2月, 2009 1 次提交
  26. 26 2月, 2009 6 次提交
    • I
      time: ntp: clean up second_overflow() · 39854fe8
      Ingo Molnar 提交于
      Impact: cleanup, no functionality changed
      
      The 'time_adj' local variable is named in a very confusing
      way because it almost shadows the 'time_adjust' global
      variable - which is used in this same function.
      
      Rename it to 'delta' - to make them stand apart more clearly.
      
      kernel/time/ntp.o:
      
         text	   data	    bss	    dec	    hex	filename
         2545	    114	    144	   2803	    af3	ntp.o.before
         2545	    114	    144	   2803	    af3	ntp.o.after
      
      md5:
         1bf0b3be564512279ba7cee299d1d2be  ntp.o.before.asm
         1bf0b3be564512279ba7cee299d1d2be  ntp.o.after.asm
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      39854fe8
    • I
      time: ntp: simplify ntp_tick_adj calculations · 069569e0
      Ingo Molnar 提交于
      Impact: micro-optimization
      
      Convert the (internal) ntp_tick_adj value we store from unscaled
      units to scaled units. This is a constant that we never modify,
      so scaling it up once during bootup is enough - we dont have to
      do it for every adjustment step.
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      069569e0
    • I
      time: ntp: make 64-bit constants more robust · 2b9d1496
      Ingo Molnar 提交于
      Impact: cleanup, no functionality changed
      
       - make PPM_SCALE an explicit s64 constant, to
         remove (s64) casts from usage sites.
      
      kernel/time/ntp.o:
      
         text	   data	    bss	    dec	    hex	filename
         2536	    114	    136	   2786	    ae2	ntp.o.before
         2536	    114	    136	   2786	    ae2	ntp.o.after
      
      md5:
         40a7728d1188aa18e83e21a81fa7b150  ntp.o.before.asm
         40a7728d1188aa18e83e21a81fa7b150  ntp.o.after.asm
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      2b9d1496
    • I
      time: ntp: refactor do_adjtimex() some more · e9629165
      Ingo Molnar 提交于
      Impact: cleanup, no functionality changed
      
      Further simplify do_adjtimex():
      
       - introduce the ntp_start_leap_timer() helper function
       - eliminate the goto adj_done complication
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      e9629165
    • I
      time: ntp: refactor do_adjtimex() · 80f22571
      Ingo Molnar 提交于
      Impact: cleanup, no functionality changed
      
      do_adjtimex() is currently a monster function with a maze of
      branches. Refactor the txc->modes setting aspects of it into
      two new helper functions:
      
      	process_adj_status()
      	process_adjtimex_modes()
      
      kernel/time/ntp.o:
      
         text	   data	    bss	    dec	    hex	filename
         2512	    114	    136	   2762	    aca	ntp.o.before
         2512	    114	    136	   2762	    aca	ntp.o.after
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      80f22571
    • I
      time: ntp: fix bug in ntp_update_offset() & do_adjtimex() · 10dd31a7
      Ingo Molnar 提交于
      Impact: change (fix) the way the NTP PLL seconds offset is initialized/tracked
      
      Fix a bug and do a micro-optimization:
      
      When PLL is enabled we do not reset time_reftime. If the PLL
      was off for a long time (for example after bootup), this is
      arguably the wrong thing to do.
      
      We already had a hack for the common boot-time case in
      ntp_update_offset(), in form of:
      
      	if (unlikely(time_status & STA_FREQHOLD || time_reftime == 0))
       		secs = 0;
      
      But the update delta should be reset later on too - not just when
      the PLL is enabled for the first time after bootup.
      
      So do it on !STA_PLL -> STA_PLL transitions.
      
      This changes behavior, as previously if ntpd was disabled for
      a long time and we restarted it, we'd run from that last update,
      with a very large delta.
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      10dd31a7