linux-stable.git/kernel/time/timekeeping.c, branch v3.16.78

time: Avoid signed overflow in timekeeping_get_ns()

2016-02-02T17:38:32+00:00

commit 35a4933a895927990772ae96fdcfd2f806929ee2 upstream.

1e75fa8 "time: Condense timekeeper.xtime into xtime_sec" replaced a call to
clocksource_cyc2ns() from timekeeping_get_ns() with an open-coded version
of the same logic to avoid keeping a semi-redundant struct timespec
in struct timekeeper.

However, the commit also introduced a subtle semantic change - where
clocksource_cyc2ns() uses purely unsigned math, the new version introduces
a signed temporary, meaning that if (delta * tk->mult) has a 63-bit
overflow the following shift will still give a negative result.  The
choice of 'maxsec' in __clocksource_updatefreq_scale() means this will
generally happen if there's a ~10 minute pause in examining the
clocksource.

This can be triggered on a powerpc KVM guest by stopping it from qemu for
a bit over 10 minutes.  After resuming time has jumped backwards several
minutes causing numerous problems (jiffies does not advance, msleep()s can
be extended by minutes..).  It doesn't happen on x86 KVM guests, because
the guest TSC is effectively frozen while the guest is stopped, which is
not the case for the powerpc timebase.

Obviously an unsigned (64 bit) overflow will only take twice as long as a
signed, 63-bit overflow.  I don't know the time code well enough to know
if that will still cause incorrect calculations, or if a 64-bit overflow
is avoided elsewhere.

Still, an incorrect forwards clock adjustment will cause less trouble than
time going backwards.  So, this patch removes the potential for
intermediate signed overflow.

Suggested-by: Laurent Vivier 
Tested-by: Laurent Vivier 
Signed-off-by: David Gibson 
Signed-off-by: John Stultz 
[ luis: backported to 3.16: adjusted context ]
Signed-off-by: Luis Henriques

timekeeping: use printk_deferred when holding timekeeping seqlock

2014-06-04T23:54:17+00:00

Jiri Bohac pointed out that there are rare but potential deadlock
possibilities when calling printk while holding the timekeeping
seqlock.

This is due to printk() triggering console sem wakeup, which can
cause scheduling code to trigger hrtimers which may try to read
the time.

Specifically, as Jiri pointed out, that path is:
  printk
    vprintk_emit
      console_unlock
        up(&console_sem)
          __up
	    wake_up_process
	      try_to_wake_up
	        ttwu_do_activate
		  ttwu_activate
		    activate_task
		      enqueue_task
		        enqueue_task_fair
			  hrtick_update
			    hrtick_start_fair
			      hrtick_start_fair
			        get_time
				  ktime_get
				    --> endless loop on
				    read_seqcount_retry(&timekeeper_seq, ...)

This patch tries to avoid this issue by using printk_deferred (previously
named printk_sched) which should defer printing via a irq_work_queue.

Signed-off-by: John Stultz 
Reported-by: Jiri Bohac 
Reviewed-by: Steven Rostedt 
Cc: Jan Kara 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: Steven Rostedt 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

kernel: use macros from compiler.h instead of attribute((...))

2014-04-07T23:36:11+00:00

To increase compiler portability there is  which
provides convenience macros for various gcc constructs.  Eg: __weak for
__attribute__((weak)).  I've replaced all instances of gcc attributes
with the right macro in the kernel subsystem.

Signed-off-by: Gideon Israel Dsouza 
Cc: "Rafael J. Wysocki" 
Cc: Ingo Molnar 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

time: Revert to calling clock_was_set_delayed() while in irq context

2014-03-28T07:07:07+00:00

In commit 47a1b796306356f35 ("tick/timekeeping: Call
update_wall_time outside the jiffies lock"), we moved to calling
clock_was_set() due to the fact that we were no longer holding
the timekeeping or jiffies lock.

However, there is still the problem that clock_was_set()
triggers an IPI, which cannot be done from the timer's hard irq
context, and will generate WARN_ON warnings.

Apparently in my earlier testing, I'm guessing I didn't bump the
dmesg log level, so I somehow missed the WARN_ONs.

Thus we need to revert back to calling clock_was_set_delayed().

Signed-off-by: John Stultz 
Cc: Linus Torvalds 
Link: http://lkml.kernel.org/r/1395963049-11923-1-git-send-email-john.stultz@linaro.org
Signed-off-by: Ingo Molnar

Merge branch 'fortglx/3.14/time' of git://git.linaro.org/people/john.stultz/linux into timers/core

2014-01-12T13:13:31+00:00

Pull timekeeping updates from John Stultz.

Signed-off-by: Ingo Molnar

timekeeping: Remove comment that's mostly out of date

2013-12-23T20:53:22+00:00

Prior to 92bb1fcf57a0c2e45f7e67fbf0a8ed475a749236 (Only
do nanosecond rounding on GENERIC_TIME_VSYSCALL_OLD
systems), the comment here was accuate, but now we can
mostly avoid the extra rounding which causes the unlikey
to be actually likely here.

So remove the out of date comment.

Signed-off-by: John Stultz

timekeeper: fix comment typo for tk_setup_internals()

2013-12-23T19:54:35+00:00

Fix trivial comment typo for tk_setup_internals().

Signed-off-by: Yijing Wang 
Signed-off-by: John Stultz

timekeeping: Fix missing timekeeping_update in suspend path

2013-12-23T19:54:35+00:00

Since 48cdc135d4840 (Implement a shadow timekeeper), we have to
call timekeeping_update() after any adjustment to the timekeeping
structure in order to make sure that any adjustments to the structure
persist.

In the timekeeping suspend path, we udpate the timekeeper
structure, so we should be sure to update the shadow-timekeeper
before releasing the timekeeping locks. Currently this isn't done.

In most cases, the next time related code to run would be
timekeeping_resume, which does update the shadow-timekeeper, but
in an abundence of caution, this patch adds the call to
timekeeping_update() in the suspend path.

Cc: Sasha Levin 
Cc: Thomas Gleixner 
Cc: Prarit Bhargava 
Cc: Richard Cochran 
Cc: Ingo Molnar 
Cc: stable  #3.10+
Signed-off-by: John Stultz

timekeeping: Fix CLOCK_TAI timer/nanosleep delays

2013-12-23T19:54:34+00:00

A think-o in the calculation of the monotonic -> tai time offset
results in CLOCK_TAI timers and nanosleeps to expire late (the
latency is ~2x the tai offset).

Fix this by adding the tai offset from the realtime offset instead
of subtracting.

Cc: Sasha Levin 
Cc: Thomas Gleixner 
Cc: Prarit Bhargava 
Cc: Richard Cochran 
Cc: Ingo Molnar 
Cc: stable  #3.10+
Signed-off-by: John Stultz

tick/timekeeping: Call update_wall_time outside the jiffies lock

2013-12-23T19:54:32+00:00

Since the xtime lock was split into the timekeeping lock and
the jiffies lock, we no longer need to call update_wall_time()
while holding the jiffies lock.

Thus, this patch splits update_wall_time() out from do_timer().

This allows us to get away from calling clock_was_set_delayed()
in update_wall_time() and instead use the standard clock_was_set()
call that previously would deadlock, as it causes the jiffies lock
to be acquired.

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

linux-stable.git/kernel/time/timekeeping.c, branch v3.16.78

time: Avoid signed overflow in timekeeping_get_ns()

timekeeping: use printk_deferred when holding timekeeping seqlock

kernel: use macros from compiler.h instead of __attribute__((...))

time: Revert to calling clock_was_set_delayed() while in irq context

Merge branch 'fortglx/3.14/time' of git://git.linaro.org/people/john.stultz/linux into timers/core

timekeeping: Remove comment that's mostly out of date

timekeeper: fix comment typo for tk_setup_internals()

timekeeping: Fix missing timekeeping_update in suspend path

timekeeping: Fix CLOCK_TAI timer/nanosleep delays

tick/timekeeping: Call update_wall_time outside the jiffies lock

kernel: use macros from compiler.h instead of attribute((...))