linux-toradex.git/arch/arm/kernel, branch v3.2.14

ARM: 7357/1: perf: fix overflow handling for xscale2 PMUs

2012-03-12T19:31:39+00:00

commit 3f31ae121348afd9ed39700ea2a63c17cd7eeed1 upstream.

xscale2 PMUs indicate overflow not via the PMU control register, but by
a separate overflow FLAG register instead.

This patch fixes the xscale2 PMU code to use this register to detect
to overflow and ensures that we clear any pending overflow when
disabling a counter.

Signed-off-by: Will Deacon 
Signed-off-by: Russell King 
Signed-off-by: Greg Kroah-Hartman

ARM: 7356/1: perf: check that we have an event in the PMU IRQ handlers

2012-03-12T19:31:39+00:00

commit f6f5a30c834135c9f2fa10400c59ebbdd9188567 upstream.

The PMU IRQ handlers in perf assume that if a counter has overflowed
then perf must be responsible. In the paranoid world of crazy hardware,
this could be false, so check that we do have a valid event before
attempting to dereference NULL in the interrupt path.

Signed-off-by: Ming Lei 
Signed-off-by: Will Deacon 
Signed-off-by: Russell King 
Signed-off-by: Greg Kroah-Hartman

ARM: 7355/1: perf: clear overflow flag when disabling counter on ARMv7 PMU

2012-03-12T19:31:38+00:00

commit 99c1745b9c76910e195889044f914b4898b7c9a5 upstream.

When disabling a counter on an ARMv7 PMU, we should also clear the
overflow flag in case an overflow occurred whilst stopping the counter.
This prevents a spurious overflow being picked up later and leading to
either false accounting or a NULL dereference.

Reported-by: Ming Lei 
Signed-off-by: Will Deacon 
Signed-off-by: Russell King 
Signed-off-by: Greg Kroah-Hartman

ARM: 7354/1: perf: limit sample_period to half max_period in non-sampling mode

2012-03-12T19:31:38+00:00

commit 5727347180ebc6b4a866fcbe00dcb39cc03acb37 upstream.

On ARM, the PMU does not stop counting after an overflow and therefore
IRQ latency affects the new counter value read by the kernel. This is
significant for non-sampling runs where it is possible for the new value
to overtake the previous one, causing the delta to be out by up to
max_period events.

Commit a737823d ("ARM: 6835/1: perf: ensure overflows aren't missed due
to IRQ latency") attempted to fix this problem by allowing interrupt
handlers to pass an overflow flag to the event update function, causing
the overflow calculation to assume that the counter passed through zero
when going from prev to new. Unfortunately, this doesn't work when
overflow occurs on the perf_task_tick path because we have the flag
cleared and end up computing a large negative delta.

This patch removes the overflow flag from armpmu_event_update and
instead limits the sample_period to half of the max_period for
non-sampling profiling runs.

Signed-off-by: Ming Lei 
Signed-off-by: Will Deacon 
Signed-off-by: Russell King 
Signed-off-by: Greg Kroah-Hartman

ARM: 7308/1: vfp: flush thread hwstate before copying ptrace registers

2012-02-13T19:16:52+00:00

commit 8130b9d7b9d858aa04ce67805e8951e3cb6e9b2f upstream.

If we are context switched whilst copying into a thread's
vfp_hard_struct then the partial copy may be corrupted by the VFP
context switching code (see "ARM: vfp: flush thread hwstate before
restoring context from sigframe").

This patch updates the ptrace VFP set code so that the thread state is
flushed before the copy, therefore disabling VFP and preventing
corruption from occurring.

Signed-off-by: Will Deacon 
Signed-off-by: Russell King 
Signed-off-by: Greg Kroah-Hartman

ARM: 7307/1: vfp: fix ptrace regset modification race

2012-02-13T19:16:52+00:00

commit 247f4993a5974e6759606c4d380748eecfd273ff upstream.

In a preemptible kernel, vfp_set() can be preempted, causing the
hardware VFP context to be switched while the thread vfp state is
being read and modified.  This leads to a race condition which can
cause the thread vfp state to become corrupted if lazy VFP context
save occurs due to preemption in between the time thread->vfpstate
is read and the time the modified state is written back.

This may occur if preemption occurs during the execution of a
ptrace() call which modifies the VFP register state of a thread.
Such instances should be very rare in most realistic scenarios --
none has been reported, so far as I am aware.  Only uniprocessor
systems should be affected, since VFP context save is not currently
lazy in SMP kernels.

The problem was introduced by my earlier patch migrating to use
regsets to implement ptrace.

This patch does a vfp_sync_hwstate() before reading
thread->vfpstate, to make sure that the thread's VFP state is not
live in the hardware registers while the registers are modified.

Thanks to Will Deacon for spotting this.

Signed-off-by: Dave Martin 
Signed-off-by: Will Deacon 
Signed-off-by: Russell King 
Signed-off-by: Greg Kroah-Hartman

ARM: 7306/1: vfp: flush thread hwstate before restoring context from sigframe

2012-02-13T19:16:52+00:00

commit 2af276dfb1722e97b190bd2e646b079a2aa674db upstream.

Following execution of a signal handler, we currently restore the VFP
context from the ucontext in the signal frame. This involves copying
from the user stack into the current thread's vfp_hard_struct and then
flushing the new data out to the hardware registers.

This is problematic when using a preemptible kernel because we could be
context switched whilst updating the vfp_hard_struct. If the current
thread has made use of VFP since the last context switch, the VFP
notifier will copy from the hardware registers into the vfp_hard_struct,
overwriting any data that had been partially copied by the signal code.

Disabling preemption across copy_from_user calls is a terrible idea, so
instead we move the VFP thread flush *before* we update the
vfp_hard_struct. Since the flushing is performed lazily, this has the
effect of disabling VFP and clearing the CPU's VFP state pointer,
therefore preventing the thread from being updated with stale data on
the next context switch.

Tested-by: Peter Maydell 
Signed-off-by: Will Deacon 
Signed-off-by: Russell King 
Signed-off-by: Greg Kroah-Hartman

ARM: unwinder: fix bisection to find origin in .idx section

2011-12-15T22:02:19+00:00

The bisection implemented in unwind_find_origin() stopped to early.  If
there is only a single entry left to check the original code just took
the end point as origin which might be wrong.

This was introduced in commit de66a979012d ("ARM: 7187/1: fix unwinding
for XIP kernels").

Reported-and-tested-by: Nick Bowler 
Signed-off-by: Uwe Kleine-König 
Signed-off-by: Linus Torvalds

ARM: 7204/1: arch/arm/kernel/setup.c: initialize arm_dma_zone_size earlier

2011-12-11T22:42:01+00:00

arm_dma_zone_size is used by arm_bootmem_free() which is called by
paging_init(). Thus it needs to be set before calling it.

Signed-off-by: Arnaud Patard 
Acked-by: Nicolas Pitre 
Cc: stable@kernel.org
Signed-off-by: Russell King

ARM: 7185/1: perf: don't assign platform_device on unsupported CPUs

2011-12-06T12:48:01+00:00

In the unlikely case that a platform registers a PMU platform_device
when running on a CPU that is unsupported by perf, we will encounter a
NULL dereference when trying to assign the platform_device to the
cpu_pmu structure.

This patch checks that the CPU is supported by perf before assigning
the platform_device.

Reported-by: Pawel Moll 
Signed-off-by: Will Deacon 
Signed-off-by: Russell King