linux.git/arch/arm/kernel, branch v3.3-rc4 Linux kernel source tree ARM: 7322/1: Print BUG instead of undefined instruction on BUG_ON() 2012-02-09T16:25:37+00:00 Stephen Boyd sboyd@codeaurora.org 2012-02-07T18:42:33+00:00 bdf800c4fceb6d8dbe65471d214eb44a61f5bfc9 The ARM kernel uses undefined instructions to implement BUG/BUG_ON(). This leads to problems where people don't read one line above the Oops message and see the "kernel BUG at ..." message and so they wrongly assume the kernel has hit an undefined instruction. Instead of printing: Internal error: Oops - undefined instruction: 0 [#1] PREEMPT SMP print Internal error: Oops - BUG: 0 [#1] PREEMPT SMP This should prevent people from thinking the BUG_ON was an undefined instruction when it was actually intentional. Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Acked-by: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> 
The ARM kernel uses undefined instructions to implement
BUG/BUG_ON(). This leads to problems where people don't read one
line above the Oops message and see the "kernel BUG at ..."
message and so they wrongly assume the kernel has hit an
undefined instruction.

Instead of printing:

 Internal error: Oops - undefined instruction: 0 [#1] PREEMPT SMP

print

 Internal error: Oops - BUG: 0 [#1] PREEMPT SMP

This should prevent people from thinking the BUG_ON was an
undefined instruction when it was actually intentional.

Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Acked-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
ARM: 7320/1: Fix proc_info table alignment 2012-02-09T16:25:37+00:00 Marc Zyngier Marc.Zyngier@arm.com 2012-02-07T01:46:38+00:00 b8b9987ffdc2ab9c5e2c1edad556b23ccb38249b With an admittedly exotic choice of configuration options (CC_OPTIMIZE_FOR_SIZE, THUMB2, some other size-minimizing ones) and compiler, the proc_info table can end up being misaligned, and the kernel being unbootable (Error: unrecognized/unsupported processor variant). Forcing the alignement to 4 bytes in the linker script fixes the issue. Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> 
With an admittedly exotic choice of configuration options
(CC_OPTIMIZE_FOR_SIZE, THUMB2, some other size-minimizing ones)
and compiler, the proc_info table can end up being misaligned,
and the kernel being unbootable (Error: unrecognized/unsupported
processor variant).

Forcing the alignement to 4 bytes in the linker script fixes the
issue.

Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
ARM: 7314/1: kuser: consistently use usr_ret for returning from helpers 2012-02-03T15:58:46+00:00 Will Deacon will.deacon@arm.com 2012-02-03T10:08:05+00:00 5a97d0ae5b5d78727b87965cba84194a9f1e06ce __kuser_cmpxchg64 has a return path using bx lr to get back to the caller. This is actually ok since the code in question is predicated on CONFIG_CPU_32v6K, but for the sake of consistency using the usr_ret macro is probably better. Acked-by: Dave Martin <dave.martin@linaro.org> Acked-by: Nicolas Pitre <nico@linaro.org> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> 
__kuser_cmpxchg64 has a return path using bx lr to get back to the caller.
This is actually ok since the code in question is predicated on
CONFIG_CPU_32v6K, but for the sake of consistency using the usr_ret
macro is probably better.

Acked-by: Dave Martin <dave.martin@linaro.org>
Acked-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
ARM: 7303/1: perf: add empty NODE event definitions for Cortex-A5 and Cortex-A15 2012-02-02T17:37:42+00:00 Will Deacon will.deacon@arm.com 2012-01-25T18:36:28+00:00 91756acb58b17aee68d055fc15b1e2550ff00801 Commit 89d6c0b5 ("perf, arch: Add generic NODE cache events") added empty NODE event definitions for the ARM PMU implementations. This was merged along with Cortex-A5 and Cortex-A15 PMU support, so they missed out on the original patch. This patch adds the empty definitions to Cortex-A5 and Cortex-A15. Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> 
Commit 89d6c0b5 ("perf, arch: Add generic NODE cache events") added
empty NODE event definitions for the ARM PMU implementations. This was
merged along with Cortex-A5 and Cortex-A15 PMU support, so they missed
out on the original patch.

This patch adds the empty definitions to Cortex-A5 and Cortex-A15.

Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
ARM: 7308/1: vfp: flush thread hwstate before copying ptrace registers 2012-02-02T17:37:42+00:00 Will Deacon will.deacon@arm.com 2012-01-30T19:23:29+00:00 8130b9d7b9d858aa04ce67805e8951e3cb6e9b2f 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. Cc: stable <stable@vger.kernel.org> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> 
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.

Cc: stable <stable@vger.kernel.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
ARM: 7307/1: vfp: fix ptrace regset modification race 2012-02-02T17:37:42+00:00 Dave Martin dave.martin@linaro.org 2012-01-30T19:22:28+00:00 247f4993a5974e6759606c4d380748eecfd273ff 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. Cc: stable <stable@vger.kernel.org> Signed-off-by: Dave Martin <dave.martin@linaro.org> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> 
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.

Cc: stable <stable@vger.kernel.org>
Signed-off-by: Dave Martin <dave.martin@linaro.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
ARM: 7306/1: vfp: flush thread hwstate before restoring context from sigframe 2012-02-02T17:37:41+00:00 Will Deacon will.deacon@arm.com 2012-01-30T19:21:42+00:00 2af276dfb1722e97b190bd2e646b079a2aa674db 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. Cc: stable <stable@vger.kernel.org> Tested-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> 
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.

Cc: stable <stable@vger.kernel.org>
Tested-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
ARM: 7299/1: ftrace: clear zero bit in reported IPs for Thumb-2 2012-01-25T09:24:37+00:00 Rabin Vincent rabin@rab.in 2012-01-24T15:52:52+00:00 d68133b5a81bd9c4b673c2a731ac1a33a9dc0cb8 The dynamic ftrace ops startup test currently fails on Thumb-2 kernels: Testing tracer function: PASSED Testing dynamic ftrace: PASSED Testing dynamic ftrace ops #1: (0 0 0 0 0) FAILED! This is because while the addresses in the mcount records do not have the zero bit set, the IP reported by the mcount call does have it set (because it is copied from the LR). This mismatch causes the ops filtering in ftrace_ops_list_func() to not call the relevant tracers. Fix this by clearing the zero bit before adjusting the LR for the mcount instruction size. Also, combine the mov+sub into a single sub instruction. Acked-by: Dave Martin <dave.martin@linaro.org> Signed-off-by: Rabin Vincent <rabin@rab.in> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> 
The dynamic ftrace ops startup test currently fails on Thumb-2 kernels:

 Testing tracer function: PASSED
 Testing dynamic ftrace: PASSED
 Testing dynamic ftrace ops #1: (0 0 0 0 0) FAILED!

This is because while the addresses in the mcount records do not have
the zero bit set, the IP reported by the mcount call does have it set
(because it is copied from the LR).  This mismatch causes the ops
filtering in ftrace_ops_list_func() to not call the relevant tracers.

Fix this by clearing the zero bit before adjusting the LR for the mcount
instruction size.  Also, combine the mov+sub into a single sub
instruction.

Acked-by: Dave Martin <dave.martin@linaro.org>
Signed-off-by: Rabin Vincent <rabin@rab.in>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
ARM: 7297/1: smp_twd: make sure timer is stopped before registering it 2012-01-23T10:20:07+00:00 Marc Zyngier Marc.Zyngier@arm.com 2012-01-20T11:24:47+00:00 c214455f3205fa20819da6d67a8b20609ff786e7 On secondary CPUs, the Timer Control Register is not reset to a sane value before the timer is registered, and the TRM doesn't seem to indicate any reset value either. In some cases, the kernel will take an interrupt too early, depending on what junk was present in the registers at reset time. The fix is to set the Timer Control Register to 0 before registering the clock_event_device and enabling the interrupt. Problem seen on VE (Cortex A5) and Tegra. Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> 
On secondary CPUs, the Timer Control Register is not reset
to a sane value before the timer is registered, and the TRM
doesn't seem to indicate any reset value either. In some cases,
the kernel will take an interrupt too early, depending on what
junk was present in the registers at reset time.

The fix is to set the Timer Control Register to 0 before
registering the clock_event_device and enabling the interrupt.

Problem seen on VE (Cortex A5) and Tegra.

Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
ARM: 7293/1: logical_cpu_map: decouple CPU mapping from SMP 2012-01-23T10:20:05+00:00 Will Deacon will.deacon@arm.com 2012-01-20T11:01:12+00:00 eb50439b92b6298bf209a982f295ba9c0f7cb30b It turns out that the logical CPU mapping is useful even when !CONFIG_SMP for manipulation of devices like interrupt and power controllers when running a UP kernel on a CPU other than 0. This can happen when kexecing a UP image from an SMP kernel. In the future, multi-cluster systems running AMP configurations will require something similar for mapping cluster IDs, so it makes sense to decouple this logic in preparation for this support. Acked-by: Yang Bai <hamo.by@gmail.com> Acked-by: Marc Zyngier <marc.zyngier@arm.com> Reported-by: Joerg Roedel <joerg.roedel@amd.com> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> 
It turns out that the logical CPU mapping is useful even when !CONFIG_SMP
for manipulation of devices like interrupt and power controllers when
running a UP kernel on a CPU other than 0. This can happen when kexecing
a UP image from an SMP kernel.

In the future, multi-cluster systems running AMP configurations will
require something similar for mapping cluster IDs, so it makes sense to
decouple this logic in preparation for this support.

Acked-by: Yang Bai <hamo.by@gmail.com>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Reported-by: Joerg Roedel <joerg.roedel@amd.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>