linux-stable.git/drivers/clocksource, branch v3.16.40

clocksource/drivers/sun4i: Clear interrupts after stopping timer in probe function

2016-11-20T01:17:18+00:00

commit b53e7d000d9e6e9fd2c6eb6b82d2783c67fd599e upstream.

The bootloader (U-boot) sometimes uses this timer for various delays.
It uses it as a ongoing counter, and does comparisons on the current
counter value. The timer counter is never stopped.

In some cases when the user interacts with the bootloader, or lets
it idle for some time before loading Linux, the timer may expire,
and an interrupt will be pending. This results in an unexpected
interrupt when the timer interrupt is enabled by the kernel, at
which point the event_handler isn't set yet. This results in a NULL
pointer dereference exception, panic, and no way to reboot.

Clear any pending interrupts after we stop the timer in the probe
function to avoid this.

Signed-off-by: Chen-Yu Tsai 
Signed-off-by: Daniel Lezcano 
Acked-by: Maxime Ripard 
Signed-off-by: Ben Hutchings

clocksource/drivers/vt8500: Increase the minimum delta

2016-02-02T19:09:28+00:00

commit f9eccf24615672896dc13251410c3f2f33a14f95 upstream.

The vt8500 clocksource driver declares itself as capable to handle the
minimum delay of 4 cycles by passing the value into
clockevents_config_and_register(). The vt8500_timer_set_next_event()
requires the passed cycles value to be at least 16. The impact is that
userspace hangs in nanosleep() calls with small delay intervals.

This problem is reproducible in Linux 4.2 starting from:
c6eb3f70d448 ('hrtimer: Get rid of hrtimer softirq')

From Russell King, more detailed explanation:

"It's a speciality of the StrongARM/PXA hardware. It takes a certain
number of OSCR cycles for the value written to hit the compare registers.
So, if a very small delta is written (eg, the compare register is written
with a value of OSCR + 1), the OSCR will have incremented past this value
before it hits the underlying hardware. The result is, that you end up
waiting a very long time for the OSCR to wrap before the event fires.

So, we introduce a check in set_next_event() to detect this and return
-ETIME if the calculated delta is too small, which causes the generic
clockevents code to retry after adding the min_delta specified in
clockevents_config_and_register() to the current time value.

min_delta must be sufficient that we don't re-trip the -ETIME check - if
we do, we will return -ETIME, forward the next event time, try to set it,
return -ETIME again, and basically lock the system up. So, min_delta
must be larger than the check inside set_next_event(). A factor of two
was chosen to ensure that this situation would never occur.

The PXA code worked on PXA systems for years, and I'd suggest no one
changes this mechanism without access to a wide range of PXA systems,
otherwise they're risking breakage."

Cc: Russell King 
Acked-by: Alexey Charkov 
Signed-off-by: Roman Volkov 
Signed-off-by: Daniel Lezcano 
Signed-off-by: Luis Henriques

clocksource: exynos_mct: Avoid blocking calls in the cpu hotplug notifier

2015-07-15T09:00:56+00:00

commit 56a94f13919c0db5958611b388e1581b4852f3c9 upstream.

Whilst testing cpu hotplug events on kernel configured with
DEBUG_PREEMPT and DEBUG_ATOMIC_SLEEP we get following BUG message,
caused by calling request_irq() and free_irq() in the context of
hotplug notification (which is in this case atomic context).

[   40.785859] CPU1: Software reset
[   40.786660] BUG: sleeping function called from invalid context at mm/slub.c:1241
[   40.786668] in_atomic(): 1, irqs_disabled(): 128, pid: 0, name: swapper/1
[   40.786678] Preemption disabled at:[<  (null)>]   (null)
[   40.786681]
[   40.786692] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 3.19.0-rc4-00024-g7dca860 #36
[   40.786698] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[   40.786728] [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
[   40.786747] [] (show_stack) from [] (dump_stack+0x70/0xbc)
[   40.786767] [] (dump_stack) from [] (kmem_cache_alloc+0xd8/0x170)
[   40.786785] [] (kmem_cache_alloc) from [] (request_threaded_irq+0x64/0x128)
[   40.786804] [] (request_threaded_irq) from [] (exynos4_local_timer_setup+0xc0/0x13c)
[   40.786820] [] (exynos4_local_timer_setup) from [] (exynos4_mct_cpu_notify+0x30/0xa8)
[   40.786838] [] (exynos4_mct_cpu_notify) from [] (notifier_call_chain+0x44/0x84)
[   40.786857] [] (notifier_call_chain) from [] (__cpu_notify+0x28/0x44)
[   40.786873] [] (__cpu_notify) from [] (secondary_start_kernel+0xec/0x150)
[   40.786886] [] (secondary_start_kernel) from [<40008764>] (0x40008764)

Interrupts cannot be requested/freed in the CPU_STARTING/CPU_DYING
notifications which run on the hotplugged cpu with interrupts and
preemption disabled.

To avoid the issue, request the interrupts for all possible cpus in
the boot code. The interrupts are marked NO_AUTOENABLE to avoid a racy
request_irq/disable_irq() sequence. The flag prevents the
request_irq() code from enabling the interrupt immediately.

The interrupt is then enabled in the CPU_STARTING notifier of the
hotplugged cpu and again disabled with disable_irq_nosync() in the
CPU_DYING notifier.

[ tglx: Massaged changelog to match the patch ]

Fixes: 7114cd749a12 ("clocksource: exynos_mct: use (request/free)_irq calls for local timer registration")
Reported-by: Krzysztof Kozlowski 
Reviewed-by: Krzysztof Kozlowski 
Tested-by: Krzysztof Kozlowski 
Tested-by: Marcin Jabrzyk 
Signed-off-by: Damian Eppel 
Cc: m.szyprowski@samsung.com
Cc: kyungmin.park@samsung.com
Cc: daniel.lezcano@linaro.org
Cc: kgene@kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Link: http://lkml.kernel.org/r/1435324984-7328-1-git-send-email-d.eppel@samsung.com
Signed-off-by: Thomas Gleixner 
Signed-off-by: Luis Henriques

clockevents: sun5i: Fix setup_irq init sequence

2015-03-30T10:10:59+00:00

commit 1096be084ac59927158ce80ff1d31c33eed0e565 upstream.

The interrupt is enabled before the handler is set. Even this bug
did not appear, it is potentially dangerous as it can lead to a
NULL pointer dereference.

Fix the error by enabling the interrupt after
clockevents_config_and_register() is called.

Signed-off-by: Yongbae Park 
Signed-off-by: Daniel Lezcano 
Signed-off-by: Luis Henriques

clocksource: efm32: Fix a NULL pointer dereference

2015-03-30T10:10:57+00:00

commit 7b8f10da3bf1056546133c9f54f49ce389fd95ab upstream.

The initialisation of the efm32 clocksource first sets up the irq and only
after that initialises the data needed for irq handling. In case this
initialisation is delayed the irq handler would dereference a NULL pointer.

I'm not aware of anything that could delay the process in such a way, but it's
better to be safe than sorry, so setup the irq only when the clock event device
is ready.

Acked-by: Uwe Kleine-König 
Signed-off-by: Yongbae Park 
Signed-off-by: Daniel Lezcano 
Signed-off-by: Luis Henriques

clocksource: arch_timer: Only use the virtual counter (CNTVCT) on arm64

2015-02-04T10:58:31+00:00

commit d6ad36913083d683aad4e02e53580c995f1a6ede upstream.

Commit 0b46b8a718c6 (clocksource: arch_timer: Fix code to use physical
timers when requested) introduces the use of physical counters in the
ARM architected timer driver. However, he arm64 kernel uses CNTVCT in
VDSO. When booting in EL2, the kernel switches to the physical timers to
make things easier for KVM but it continues to use the virtual counter
both in user and kernel. While in such scenario CNTVCT == CNTPCT (since
CNTVOFF is initialised by the kernel to 0), we want to spot firmware
bugs corrupting CNTVOFF early (which would affect CNTVCT).

Signed-off-by: Catalin Marinas 
Tested-by: Yingjoe Chen 
Cc: Daniel Lezcano 
Signed-off-by: Arnd Bergmann 
Cc: Mark Rutland 
Signed-off-by: Luis Henriques

clocksource: exynos_mct: Fix bitmask regression for exynos4_mct_write

2015-02-02T10:01:01+00:00

commit 8c38d28ba8da98f7102c31d35359b4dbe9d1f329 upstream.

EXYNOS4_MCT_L_MASK is defined as 0xffffff00, so applying this bitmask
produces a number outside the range 0x00 to 0xff, which always results
in execution of the default switch statement.

Obviously this is wrong and git history shows that the bitmask inversion
was incorrectly set during a refactoring of the MCT code.

Fix this by putting the inversion at the correct position again.

Acked-by: Kukjin Kim 
Reported-by: GP Orcullo 
Reviewed-by: Doug Anderson 
Signed-off-by: Tobias Jakobi 
Signed-off-by: Daniel Lezcano 
Signed-off-by: Luis Henriques

clocksource: arch_timer: Fix code to use physical timers when requested

2015-01-15T10:43:32+00:00

commit 0b46b8a718c6e90910a1b1b0fe797be3c167e186 upstream.

This is a bug fix for using physical arch timers when
the arch_timer_use_virtual boolean is false.  It restores the
arch_counter_get_cntpct() function after removal in

0d651e4e "clocksource: arch_timer: use virtual counters"

We need this on certain ARMv7 systems which are architected like this:

* The firmware doesn't know and doesn't care about hypervisor mode and
  we don't want to add the complexity of hypervisor there.

* The firmware isn't involved in SMP bringup or resume.

* The ARCH timer come up with an uninitialized offset between the
  virtual and physical counters.  Each core gets a different random
  offset.

* The device boots in "Secure SVC" mode.

* Nothing has touched the reset value of CNTHCTL.PL1PCEN or
  CNTHCTL.PL1PCTEN (both default to 1 at reset)

One example of such as system is RK3288 where it is much simpler to
use the physical counter since there's nobody managing the offset and
each time a core goes down and comes back up it will get reinitialized
to some other random value.

Fixes: 0d651e4e65e9 ("clocksource: arch_timer: use virtual counters")
Signed-off-by: Sonny Rao 
Acked-by: Catalin Marinas 
Acked-by: Daniel Lezcano 
Signed-off-by: Olof Johansson 
[ luis: backported to 3.16: adjusted context ]
Signed-off-by: Luis Henriques

clocksource: arm_arch_timer: Change clocksource name if CP15 unavailable

2015-01-15T10:43:31+00:00

commit 423bd69e69f565167ba14e2fe61df76c3c4a0d26 upstream.

The arm and arm64 VDSOs need CP15 access to the architected counter.
If this is unavailable (which is allowed by ARM v7), indicate this by
changing the clocksource name to "arch_mem_counter" before registering
the clocksource.

Suggested by Stephen Boyd.

Signed-off-by: Nathan Lynch 
Reviewed-by: Stephen Boyd 
Signed-off-by: Daniel Lezcano 
Acked-by: Will Deacon 
Signed-off-by: Luis Henriques

clockevent: sun4i: Fix race condition in the probe code

2014-12-01T10:26:04+00:00

commit 6bab4a8a1888729f17f4923cc5867e4674f66333 upstream.

The interrupts were activated and the handler registered before the clockevent
was registered in the probe function.

The interrupt handler, however, was making the assumption that the clockevent
device was registered.

That could cause a null pointer dereference if the timer interrupt was firing
during this narrow window.

Fix that by moving the clockevent registration before the interrupt is enabled.

Reported-by: Roman Byshko 
Signed-off-by: Maxime Ripard 
Signed-off-by: Daniel Lezcano 
Signed-off-by: Luis Henriques