linux-stable.git/arch/arm/kernel, branch v3.12.44

ARM: fix missing syscall trace exit

2015-06-02T15:01:14+00:00

commit 1b97937246d8b97c0760d16d8992c7937bdf5e6a upstream.

Josh Stone reports:

  I've discovered a case where both arm and arm64 will miss a ptrace
  syscall-exit that they should report.  If the syscall is entered
  without TIF_SYSCALL_TRACE set, then it goes on the fast path.  It's
  then possible to have TIF_SYSCALL_TRACE added in the middle of the
  syscall, but ret_fast_syscall doesn't check this flag again.

Fix this by always checking for a syscall trace in the fast exit path.

Reported-by: Josh Stone 
Signed-off-by: Russell King 
Signed-off-by: Jiri Slaby

ARM: virt: fix wrong HSCTLR.EE bit setting

2015-04-30T09:15:07+00:00

commit af92394efc8be73edd2301fc15f9b57fd430cd18 upstream.

HSCTLR.EE is defined as bit[25] referring to arm manual
DDI0606C.b(p1590).

Reviewed-by: Marc Zyngier 
Signed-off-by: Li Liu 
Signed-off-by: Marc Zyngier 
Signed-off-by: Shannon Zhao 
Signed-off-by: Jiri Slaby

ARM: KVM: introduce per-vcpu HYP Configuration Register

2015-04-30T09:15:04+00:00

commit ac30a11e8e92a03dbe236b285c5cbae0bf563141 upstream.

So far, KVM/ARM used a fixed HCR configuration per guest, except for
the VI/VF/VA bits to control the interrupt in absence of VGIC.

With the upcoming need to dynamically reconfigure trapping, it becomes
necessary to allow the HCR to be changed on a per-vcpu basis.

The fix here is to mimic what KVM/arm64 already does: a per vcpu HCR
field, initialized at setup time.

Signed-off-by: Marc Zyngier 
Reviewed-by: Christoffer Dall 
Acked-by: Catalin Marinas 
Signed-off-by: Shannon Zhao 
Signed-off-by: Jiri Slaby

ARM: Correct BUG() assembly to ensure it is endian-agnostic

2015-04-09T12:13:37+00:00

commit 63328070eff2f4fd730c86966a0dbc976147c39f upstream.

Currently BUG() uses .word or .hword to create the necessary illegal
instructions. However if we are building BE8 then these get swapped
by the linker into different illegal instructions in the text. This
means that the BUG() macro does not get trapped properly.

Change to using  to provide the necessary ARM instruction
building as we cannot rely on gcc/gas having the `.inst` instructions
which where added to try and resolve this issue (reported by Dave Martin
).

Signed-off-by: Ben Dooks 
Reviewed-by: Dave Martin 
Signed-off-by: Jiri Slaby

Revert "ARM: 7830/1: delay: don't bother reporting bogomips in /proc/cpuinfo"

2015-01-26T13:39:06+00:00

commit 4bf9636c39ac70da091d5a2e28d3448eaa7f115c upstream.

Commit 9fc2105aeaaf ("ARM: 7830/1: delay: don't bother reporting
bogomips in /proc/cpuinfo") breaks audio in python, and probably
elsewhere, with message

  FATAL: cannot locate cpu MHz in /proc/cpuinfo

I'm not the first one to hit it, see for example

  https://theredblacktree.wordpress.com/2014/08/10/fatal-cannot-locate-cpu-mhz-in-proccpuinfo/
  https://devtalk.nvidia.com/default/topic/765800/workaround-for-fatal-cannot-locate-cpu-mhz-in-proc-cpuinf/?offset=1

Reading original changelog, I have to say "Stop breaking working setups.
You know who you are!".

Signed-off-by: Pavel Machek 
Signed-off-by: Linus Torvalds 
Signed-off-by: Jiri Slaby

ARM: 8226/1: cacheflush: get rid of restarting block

2014-12-06T14:18:20+00:00

commit 3f4aa45ceea5789a4aade536acc27f2e0d3da5e1 upstream.

We cannot restart cacheflush safely if a process provides user-defined
signal handler and signal is pending. In this case -EINTR is returned
and it is expected that process re-invokes syscall. However, there are
a few problems with that:
 * looks like nobody bothers checking return value from cacheflush
 * but if it did, we don't provide the restart address for that, so the
   process has to use the same range again
 * ...and again, what might lead to looping forever

So, remove cacheflush restarting code and terminate cache flushing
as early as fatal signal is pending.

Reported-by: Chanho Min 
Signed-off-by: Vladimir Murzin 
Acked-by: Will Deacon 
Signed-off-by: Russell King 
Signed-off-by: Jiri Slaby

ARM: probes: fix instruction fetch order with

2014-11-19T17:38:26+00:00

commit 888be25402021a425da3e85e2d5a954d7509286e upstream.

If we are running BE8, the data and instruction endianness do not
match, so use  to correctly translate memory accesses
into ARM instructions.

Acked-by: Jon Medhurst 
Signed-off-by: Ben Dooks 
[taras.kondratiuk@linaro.org: fixed Thumb instruction fetch order]
Signed-off-by: Taras Kondratiuk 
[wangnan: backport to 3.10 and 3.14:
 - adjust context
 - backport all changes on arch/arm/kernel/probes.c to
   arch/arm/kernel/kprobes-common.c since we don't have
   commit c18377c303787ded44b7decd7dee694db0f205e9.
 - After the above adjustments, becomes same to Taras Kondratiuk's
   original patch:
     http://lists.linaro.org/pipermail/linaro-kernel/2014-January/010346.html
]
Signed-off-by: Wang Nan 
Signed-off-by: Jiri Slaby

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

2014-10-13T13:41:07+00:00

commit fbfb872f5f417cea48760c535e0ff027c88b507a upstream.

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 
Signed-off-by: Russell King 
Signed-off-by: Jiri Slaby

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

2014-10-13T13:41:07+00:00

commit a040803a9d6b8c1876d3487a5cb69602ebcbb82c upstream.

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 
Signed-off-by: Russell King 
Signed-off-by: Jiri Slaby

ARM: 7897/1: kexec: Use the right ISA for relocate_new_kernel

2014-10-01T15:24:26+00:00

commit e2ccba49085ab5d71b092de2a5176eb9b19cc876 upstream.

Copying a function with memcpy() and then trying to execute the
result isn't trivially portable to Thumb.

This patch modifies the kexec soft restart code to copy its
assembler trampoline relocate_new_kernel() using fncpy() instead,
so that relocate_new_kernel can be in the same ISA as the rest of
the kernel without problems.

Signed-off-by: Dave Martin 
Acked-by: Will Deacon 
Reported-by: Taras Kondratiuk 
Tested-by: Taras Kondratiuk 
Signed-off-by: Russell King 
Signed-off-by: Jiri Slaby