linux-stable.git/kernel/time, branch linux-2.6.32.y

tick: Cleanup NOHZ per cpu data on cpu down

2013-06-10T09:42:13+00:00

commit 4b0c0f294f60abcdd20994a8341a95c8ac5eeb96 upstream.

Prarit reported a crash on CPU offline/online. The reason is that on
CPU down the NOHZ related per cpu data of the dead cpu is not cleaned
up. If at cpu online an interrupt happens before the per cpu tick
device is registered the irq_enter() check potentially sees stale data
and dereferences a NULL pointer.

Cleanup the data after the cpu is dead.

Reported-by: Prarit Bhargava 
Cc: Mike Galbraith 
Link: http://lkml.kernel.org/r/alpine.LFD.2.02.1305031451561.2886@ionos
Signed-off-by: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Willy Tarreau

clockevents: Don't allow dummy broadcast timers

2013-06-10T09:42:12+00:00

commit a7dc19b8652c862d5b7c4d2339bd3c428bd29c4a upstream.

Currently tick_check_broadcast_device doesn't reject clock_event_devices
with CLOCK_EVT_FEAT_DUMMY, and may select them in preference to real
hardware if they have a higher rating value. In this situation, the
dummy timer is responsible for broadcasting to itself, and the core
clockevents code may attempt to call non-existent callbacks for
programming the dummy, eventually leading to a panic.

This patch makes tick_check_broadcast_device always reject dummy timers,
preventing this problem.

Signed-off-by: Mark Rutland 
Cc: linux-arm-kernel@lists.infradead.org
Cc: Jon Medhurst (Tixy) 
Signed-off-by: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Willy Tarreau

2.6.32.y: timekeeping: Fix nohz issue with commit 61b76840ddee647c0c223365378c3f394355b7d7

2013-06-10T09:42:12+00:00

Commit 61b76840ddee647c0c223365378c3f394355b7d7 ("time: Avoid
making adjustments if we haven't accumulated anything")
introduced a regression with nohz.

Basically with kernels between 2.6.20-something to 2.6.32,
we accumulate time in half second chunks, rather then every
timer-tick. This was added because when NOHZ landed, if you
were idle for a few seconds, you had to spin for every tick
we skipped in the accumulation loop, which created some bad
latencies.

However, this required that we create the xtime_cache() which
was still updated each tick, so that filesystem timestamps,
etc continued to see time increment normally.

Of course, the xtime_cache is updated at the bottom of
update_wall_time(). So the early return on
(offset < timekeeper.cycle_interval), added by the problematic
commit causes the xtime_cache to not be updated.

This can cause code using current_kernel_time() (like the mqueue
code) or hrtimer_get_softirq_time(), which uses the non-updated
xtime_cache, to see timers to fire with very coarse half-second
granularity.

Many thanks to Romain for describing the issue clearly,
providing test case to reproduce it and helping with testing
the solution.

This change is for 2.6.32-stable ONLY!

Cc: stable@vger.kernel.org
Cc: Willy Tarreau 
Cc: Romain Francoise 
Reported-by: Romain Francoise 
Tested-by: Romain Francoise 
Signed-off-by: John Stultz 
Signed-off-by: Willy Tarreau

ntp: Fix STA_INS/DEL clearing bug

2012-10-07T21:37:58+00:00

commit 6b1859dba01c7d512b72d77e3fd7da8354235189 upstream.

In commit 6b43ae8a619d17c4935c3320d2ef9e92bdeed05d, I
introduced a bug that kept the STA_INS or STA_DEL bit
from being cleared from time_status via adjtimex()
without forcing STA_PLL first.

Usually once the STA_INS is set, it isn't cleared
until the leap second is applied, so its unlikely this
affected anyone. However during testing I noticed it
took some effort to cancel a leap second once STA_INS
was set.

Signed-off-by: John Stultz 
Cc: Ingo Molnar 
Cc: Peter Zijlstra 
Cc: Richard Cochran 
Cc: Prarit Bhargava 
Link: http://lkml.kernel.org/r/1342156917-25092-2-git-send-email-john.stultz@linaro.org
Signed-off-by: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Willy Tarreau

ntp: Fix integer overflow when setting time

2012-10-07T21:37:34+00:00

commit a078c6d0e6288fad6d83fb6d5edd91ddb7b6ab33 upstream.

'long secs' is passed as divisor to div_s64, which accepts a 32bit
divisor. On 64bit machines that value is trimmed back from 8 bytes
back to 4, causing a divide by zero when the number is bigger than
(1 << 32) - 1 and all 32 lower bits are 0.

Use div64_long() instead.

Signed-off-by: Sasha Levin 
Cc: johnstul@us.ibm.com
Link: http://lkml.kernel.org/r/1331829374-31543-2-git-send-email-levinsasha928@gmail.com
Signed-off-by: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman 
[WT: div64_long() does not exist on 2.6.32 and needs a deeper backport than
 desired. Instead, address the issue by controlling that the divisor is
 correct for use as an s32 divisor]
Signed-off-by: Willy Tarreau

time: Move ktime_t overflow checking into timespec_valid_strict

2012-10-07T21:37:11+00:00

This is a -stable backport of cee58483cf56e0ba355fdd97ff5e8925329aa936

Andreas Bombe reported that the added ktime_t overflow checking added to
timespec_valid in commit 4e8b14526ca7 ("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: Andreas Bombe 
Cc: Zhouping Liu 
Cc: Ingo Molnar 
Cc: Prarit Bhargava 
Cc: Thomas Gleixner 
Cc: stable@vger.kernel.org
Signed-off-by: John Stultz 
Signed-off-by: Linus Torvalds 
Cc: Linux Kernel 
Signed-off-by: John Stultz 
Signed-off-by: Willy Tarreau

time: Avoid making adjustments if we haven't accumulated anything

2012-10-07T21:37:10+00:00

This is a -stable backport of bf2ac312195155511a0f79325515cbb61929898a

If update_wall_time() is called and the current offset isn't large
enough to accumulate, avoid re-calling timekeeping_adjust which may
change the clock freq and can cause 1ns inconsistencies with
CLOCK_REALTIME_COARSE/CLOCK_MONOTONIC_COARSE.

Signed-off-by: John Stultz 
Cc: Prarit Bhargava 
Cc: Ingo Molnar 
Cc: stable@vger.kernel.org
Link: http://lkml.kernel.org/r/1345595449-34965-5-git-send-email-john.stultz@linaro.org
Signed-off-by: Thomas Gleixner 
Cc: Linux Kernel 
Signed-off-by: John Stultz 
Signed-off-by: Willy Tarreau

time: Improve sanity checking of timekeeping inputs

2012-10-07T21:37:09+00:00

This is a -stable backport of 4e8b14526ca7fb046a81c94002c1c43b6fdf0e9b

Unexpected behavior could occur if the time is set to a value large
enough to overflow a 64bit ktime_t (which is something larger then the
year 2262).

Also unexpected behavior could occur if large negative offsets are
injected via adjtimex.

So this patch improves the sanity check timekeeping inputs by
improving the timespec_valid() check, and then makes better use of
timespec_valid() to make sure we don't set the time to an invalid
negative value or one that overflows ktime_t.

Note: This does not protect from setting the time close to overflowing
ktime_t and then letting natural accumulation cause the overflow.

Reported-by: CAI Qian 
Reported-by: Sasha Levin 
Signed-off-by: John Stultz 
Cc: Peter Zijlstra 
Cc: Prarit Bhargava 
Cc: Zhouping Liu 
Cc: Ingo Molnar 
Cc: stable@vger.kernel.org
Link: http://lkml.kernel.org/r/1344454580-17031-1-git-send-email-john.stultz@linaro.org
Signed-off-by: Thomas Gleixner 
Cc: Linux Kernel 
Signed-off-by: John Stultz 
Signed-off-by: Willy Tarreau

timekeeping: Add missing update call in timekeeping_resume()

2012-10-07T21:37:09+00:00

This is a backport of 3e997130bd2e8c6f5aaa49d6e3161d4d29b43ab0

The leap second rework unearthed another issue of inconsistent data.

On timekeeping_resume() the timekeeper data is updated, but nothing
calls timekeeping_update(), so now the update code in the timer
interrupt sees stale values.

This has been the case before those changes, but then the timer
interrupt was using stale data as well so this went unnoticed for quite
some time.

Add the missing update call, so all the data is consistent everywhere.

Reported-by: Andreas Schwab 
Reported-and-tested-by: "Rafael J. Wysocki" 
Reported-and-tested-by: Martin Steigerwald 
Cc: LKML 
Cc: Linux PM list 
Cc: John Stultz 
Cc: Ingo Molnar 
Cc: Peter Zijlstra ,
Cc: Prarit Bhargava 
Cc: stable@vger.kernel.org
Signed-off-by: Thomas Gleixner 
Signed-off-by: John Stultz 
Signed-off-by: Linus Torvalds 
Cc: Prarit Bhargava 
Cc: Thomas Gleixner 
Cc: Linux Kernel 
Signed-off-by: John Stultz 
Signed-off-by: Willy Tarreau

timekeeping: Provide hrtimer update function

2012-10-07T21:37:08+00:00

This is a backport of f6c06abfb3972ad4914cef57d8348fcb2932bc3b

To finally fix the infamous leap second issue and other race windows
caused by functions which change the offsets between the various time
bases (CLOCK_MONOTONIC, CLOCK_REALTIME and CLOCK_BOOTTIME) we need a
function which atomically gets the current monotonic time and updates
the offsets of CLOCK_REALTIME and CLOCK_BOOTTIME with minimalistic
overhead. The previous patch which provides ktime_t offsets allows us
to make this function almost as cheap as ktime_get() which is going to
be replaced in hrtimer_interrupt().

Signed-off-by: Thomas Gleixner 
Reviewed-by: Ingo Molnar 
Acked-by: Peter Zijlstra 
Acked-by: Prarit Bhargava 
Cc: stable@vger.kernel.org
Signed-off-by: John Stultz 
Link: http://lkml.kernel.org/r/1341960205-56738-7-git-send-email-johnstul@us.ibm.com
Signed-off-by: Thomas Gleixner 
Cc: Prarit Bhargava 
Cc: Thomas Gleixner 
Cc: Linux Kernel 
Signed-off-by: John Stultz 
Signed-off-by: Willy Tarreau