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

ARM: 8179/1: kprobes-test: Fix compile error "bad immediate value for offset"

2014-09-30T15:55:24+00:00

When compiling kprobes-test-arm.c the following error has been observed

/tmp/ccoT403o.s:21439: Error: bad immediate value for offset (4168)

This is caused by the compiler spilling it's literal pool too far away
from the site which is trying to reference it with a PC relative load.
This arises because the compiler is underestimating the size of the
inline assembler code present, which apparently it approximates as 4
bytes per line or instruction.

We fix this problem by moving the operations which generate more than
4 bytes out of the text section. Specifically, moving the .ascii
directives to the .rodata section.

Signed-off-by: Jon Medhurst 
Signed-off-by: Russell King

ARM: 8149/1: perf: Don't sleep while atomic when enabling per-cpu interrupts

2014-09-16T15:09:33+00:00

Rob Clark reports a sleeping while atomic bug when using perf.

BUG: sleeping function called from invalid context at ../kernel/locking/mutex.c:583
in_atomic(): 1, irqs_disabled(): 128, pid: 0, name: swapper/0
------------[ cut here ]------------
WARNING: CPU: 2 PID: 4828 at ../kernel/locking/mutex.c:479 mutex_lock_nested+0x3a0/0x3e8()
DEBUG_LOCKS_WARN_ON(in_interrupt())
Modules linked in:
CPU: 2 PID: 4828 Comm: Xorg.bin Tainted: G        W      3.17.0-rc3-00234-gd535c45-dirty #819
[] (unwind_backtrace) from [] (show_stack+0x10/0x14)
[] (show_stack) from [] (dump_stack+0x98/0xb8)
[] (dump_stack) from [] (warn_slowpath_common+0x70/0x8c)
[] (warn_slowpath_common) from [] (warn_slowpath_fmt+0x30/0x40)
[] (warn_slowpath_fmt) from [] (mutex_lock_nested+0x3a0/0x3e8)
[] (mutex_lock_nested) from [] (irq_find_host+0x20/0x9c)
[] (irq_find_host) from [] (of_irq_get+0x28/0x48)
[] (of_irq_get) from [] (platform_get_irq+0x1c/0x8c)
[] (platform_get_irq) from [] (cpu_pmu_enable_percpu_irq+0x14/0x38)
[] (cpu_pmu_enable_percpu_irq) from [] (flush_smp_call_function_queue+0x88/0x178)
[] (flush_smp_call_function_queue) from [] (handle_IPI+0x88/0x160)
[] (handle_IPI) from [] (gic_handle_irq+0x64/0x68)
[] (gic_handle_irq) from [] (__irq_svc+0x44/0x5c)
Exception stack(0xe63ddea0 to 0xe63ddee8)
dea0: 00000001 00000001 00000000 c2f3b200 c16db380 c032d4a0 e63ddf40 60010013
dec0: 00000000 001fbfd4 00000100 00000000 00000001 e63ddee8 c0284770 c02a2e30
dee0: 20010013 ffffffff
[] (__irq_svc) from [] (ktime_get_ts64+0x1c8/0x200)
[] (ktime_get_ts64) from [] (poll_select_set_timeout+0x60/0xa8)
[] (poll_select_set_timeout) from [] (SyS_select+0xa8/0x118)
[] (SyS_select) from [] (ret_fast_syscall+0x0/0x48)
---[ end trace 0bb583b46342da6f ]---
INFO: lockdep is turned off.

We don't really need to get the platform irq again when we're
enabling or disabling the per-cpu irq. Furthermore, we don't
really need to set and clear bits in the active_irqs bitmask
because that's only used in the non-percpu irq case to figure out
when the last CPU PMU has been disabled. Just pass the irq
directly to the enable/disable functions to clean all this up.
This should be slightly more efficient and also fix the
scheduling while atomic bug.

Fixes: bbd64559376f "ARM: perf: support percpu irqs for the CPU PMU"

Reported-by: Rob Clark 
Acked-by: Will Deacon 
Cc: stable@vger.kernel.org
Signed-off-by: Stephen Boyd 
Signed-off-by: Russell King

ARM: 8148/1: flush TLS and thumbee register state during exec

2014-09-16T15:09:32+00:00

The TPIDRURO and TPIDRURW registers need to be flushed during exec;
otherwise TLS information is potentially leaked.  TPIDRURO in
particular needs careful treatment.  Since flush_thread basically
needs the same code used to set the TLS in arm_syscall, pull that into
a common set_tls helper in tls.h and use it in both places.

Similarly, TEEHBR needs to be cleared during exec as well.  Clearing
its save slot in thread_info isn't right as there is no guarantee
that a thread switch will occur before the new program runs.  Just
setting the register directly is sufficient.

Signed-off-by: Nathan Lynch 
Acked-by: Will Deacon 
Cc: 
Signed-off-by: Russell King

ARM: 8151/1: add missing exports for asm functions required by get_user macro

2014-09-16T15:09:30+00:00

Previous commits that dealt with get_user for 64bit type missed to
export proper functions, so if get_user macro with particular target/value
types are used by kernel module modpost would produce 'undefined!' error.
Solution is to export all required functions.

Signed-off-by: Victor Kamensky 
Signed-off-by: Russell King

ARM: 8135/1: Fix in-correct barrier usage in SWP{B} emulation

2014-09-12T16:38:58+00:00

According to the ARM ARMv7, explicit barriers are necessary when using
synchronisation primitives such as SWP{B}. The use of these
instructions does not automatically imply a barrier and any ordering
requirements by the software must be explicitly expressed with the use
of suitable barriers.

Based on this, remove the barriers from SWP{B} emulation.

Acked-by: Will Deacon 
Signed-off-by: Punit Agrawal 
Signed-off-by: Russell King

ARM: 8133/1: use irq_set_affinity with force=false when migrating irqs

2014-09-02T19:55:25+00:00

Since commit 1dbfa187dad ("ARM: irq migration: force migration off CPU
going down") the ARM interrupt migration code on cpu offline calls
irqchip.irq_set_affinity() with the argument force=true. At the point
of this change the argument had no effect because it was not used by
any interrupt chip driver and there was no semantics defined.

This changed with commit 01f8fa4f01d8 ("genirq: Allow forcing cpu
affinity of interrupts") which made the force argument useful to route
interrupts to not yet online cpus without checking the target cpu
against the cpu online mask. The following commit ffde1de64012
("irqchip: gic: Support forced affinity setting") implemented this for
the GIC interrupt controller.

As a consequence the ARM cpu offline irq migration fails if CPU0 is
offlined, because CPU0 is still set in the affinity mask and the
validataion against cpu online mask is skipped to the force argument
being true. The following first_cpu(mask) selection always selects
CPU0 as the target.

Solve the issue by calling irq_set_affinity() with force=false from
the CPU offline irq migration code so the GIC driver validates the
affinity mask against CPU online mask and therefore removes CPU0 from
the possible target candidates.

Tested on TC2 hotpluging CPU0 in and out. Without this patch the system
locks up as the IRQs are not migrated away from CPU0.

Signed-off-by: Sudeep Holla 
Acked-by: Thomas Gleixner 
Acked-by: Mark Rutland 
Cc:  # 3.10.x
Signed-off-by: Russell King

ARM: 8129/1: errata: work around Cortex-A15 erratum 830321 using dummy strex

2014-08-27T14:40:13+00:00

On revisions of Cortex-A15 prior to r3p3, a CLREX instruction at PL1 may
falsely trigger a watchpoint exception, leading to potential data aborts
during exception return and/or livelock.

This patch resolves the issue in the following ways:

  - Replacing our uses of CLREX with a dummy STREX sequence instead (as
    we did for v6 CPUs).

  - Removing the clrex code from v7_exit_coherency_flush and derivatives,
    since this only exists as a minor performance improvement when
    non-cached exclusives are in use (Linux doesn't use these).

Benchmarking on a variety of ARM cores revealed no measurable
performance difference with this change applied, so the change is
performed unconditionally and no new Kconfig entry is added.

Signed-off-by: Mark Rutland 
Signed-off-by: Will Deacon 
Cc: stable@vger.kernel.org
Signed-off-by: Russell King

ARM: 8127/1: module: add support for R_ARM_TARGET1 relocations

2014-08-27T14:40:11+00:00

Kernel module build with GCOV profiling fails to load with the
following error:

 $ insmod test_module.ko
   test_module: unknown relocation: 38
   insmod: can't insert 'test_module.ko': invalid module format

This happens because constructor pointers in the .init_array section
have not supported R_ARM_TARGET1 relocation type.

Documentation (ELF for the ARM Architecture) says:
    "The relocation must be processed either in the same way as R_ARM_REL32 or
     as R_ARM_ABS32: a virtual platform must specify which method is used."

Since kernel expects to see absolute addresses in .init_array R_ARM_TARGET1
relocation type should be treated the same way as R_ARM_ABS32.

Signed-off-by: Andrey Ryabinin 
Signed-off-by: Russell King

Merge tag 'trace-ipi-tracepoints' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace

2014-08-10T00:33:44+00:00

Pull IPI tracepoints for ARM from Steven Rostedt:
 "Nicolas Pitre added generic tracepoints for tracing IPIs and updated
  the arm and arm64 architectures.  It required some minor updates to
  the generic tracepoint system, so it had to wait for me to implement
  them"

* tag 'trace-ipi-tracepoints' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
  ARM64: add IPI tracepoints
  ARM: add IPI tracepoints
  tracepoint: add generic tracepoint definitions for IPI tracing
  tracing: Do not do anything special with tracepoint_string when tracing is disabled

ARM: wire up memfd_create syscall

2014-08-09T13:07:59+00:00

Add the memfd_create syscall to ARM.

Signed-off-by: Russell King