linux-stable.git/arch/arm/kernel, branch v4.1.44

ARM: 8643/3: arm/ptrace: Preserve previous registers for short regset write

2017-03-06T22:31:12+00:00

[ Upstream commit 228dbbfb5d77f8e047b2a1d78da14b7158433027 ]

Ensure that if userspace supplies insufficient data to
PTRACE_SETREGSET to fill all the registers, the thread's old
registers are preserved.

Cc:  # 3.0.x-
Fixes: 5be6f62b0059 ("ARM: 6883/1: ptrace: Migrate to regsets framework")
Signed-off-by: Dave Martin 
Acked-by: Russell King 
Signed-off-by: Russell King 
Signed-off-by: Sasha Levin

ARM: 8634/1: hw_breakpoint: blacklist Scorpion CPUs

2017-03-06T22:29:18+00:00

[ Upstream commit ddc37832a1349f474c4532de381498020ed71d31 ]

On APQ8060, the kernel crashes in arch_hw_breakpoint_init, taking an
undefined instruction trap within write_wb_reg. This is because Scorpion
CPUs erroneously appear to set DBGPRSR.SPD when WFI is issued, even if
the core is not powered down. When DBGPRSR.SPD is set, breakpoint and
watchpoint registers are treated as undefined.

It's possible to trigger similar crashes later on from userspace, by
requesting the kernel to install a breakpoint or watchpoint, as we can
go idle at any point between the reset of the debug registers and their
later use. This has always been the case.

Given that this has always been broken, no-one has complained until now,
and there is no clear workaround, disable hardware breakpoints and
watchpoints on Scorpion to avoid these issues.

Signed-off-by: Mark Rutland 
Reported-by: Linus Walleij 
Reviewed-by: Stephen Boyd 
Acked-by: Will Deacon 
Cc: Russell King 
Cc: stable@vger.kernel.org
Signed-off-by: Russell King 
Signed-off-by: Sasha Levin

[PATCH] arm: fix handling of F_OFD_... in oabi_fcntl64()

2016-09-11T13:56:59+00:00

[ Upstream commit 76cc404bfdc0d419c720de4daaf2584542734f42 ]

Cc: stable@vger.kernel.org # 3.15+
Reviewed-by: Jeff Layton 
Signed-off-by: Al Viro 
Signed-off-by: Sasha Levin

ARM: fix PTRACE_SETVFPREGS on SMP systems

2016-06-17T19:37:18+00:00

[ Upstream commit e2dfb4b880146bfd4b6aa8e138c0205407cebbaf ]

PTRACE_SETVFPREGS fails to properly mark the VFP register set to be
reloaded, because it undoes one of the effects of vfp_flush_hwstate().

Specifically vfp_flush_hwstate() sets thread->vfpstate.hard.cpu to
an invalid CPU number, but vfp_set() overwrites this with the original
CPU number, thereby rendering the hardware state as apparently "valid",
even though the software state is more recent.

Fix this by reverting the previous change.

Cc: 
Fixes: 8130b9d7b9d8 ("ARM: 7308/1: vfp: flush thread hwstate before copying ptrace registers")
Acked-by: Will Deacon 
Tested-by: Simon Marchi 
Signed-off-by: Russell King 
Signed-off-by: Sasha Levin

ARM: 8425/1: kgdb: Don't try to stop the machine when setting breakpoints

2015-10-22T21:43:13+00:00

commit 7ae85dc7687c7e7119053d83d02c560ea217b772 upstream.

In (23a4e40 arm: kgdb: Handle read-only text / modules) we moved to
using patch_text() to set breakpoints so that we could handle the case
when we had CONFIG_DEBUG_RODATA.  That patch used patch_text().
Unfortunately, patch_text() assumes that we're not in atomic context
when it runs since it needs to grab a mutex and also wait for other
CPUs to stop (which it does with a completion).

This would result in a stack crawl if you had
CONFIG_DEBUG_ATOMIC_SLEEP and tried to set a breakpoint in kgdb.  The
crawl looked something like:

 BUG: scheduling while atomic: swapper/0/0/0x00010007
 CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.2.0-rc7-00133-geb63b34 #1073
 Hardware name: Rockchip (Device Tree)
  (unwind_backtrace) from [] (show_stack+0x20/0x24)
  (show_stack) from [] (dump_stack+0x84/0xb8)
  (dump_stack) from [] (__schedule_bug+0x54/0x6c)
  (__schedule_bug) from [] (__schedule+0x80/0x668)
  (__schedule) from [] (schedule+0xb8/0xd4)
  (schedule) from [] (schedule_timeout+0x2c/0x234)
  (schedule_timeout) from [] (wait_for_common+0xf4/0x188)
  (wait_for_common) from [] (wait_for_completion+0x20/0x24)
  (wait_for_completion) from [] (__stop_cpus+0x58/0x70)
  (__stop_cpus) from [] (stop_cpus+0x3c/0x54)
  (stop_cpus) from [] (__stop_machine+0xcc/0xe8)
  (__stop_machine) from [] (stop_machine+0x34/0x44)
  (stop_machine) from [] (patch_text+0x28/0x34)
  (patch_text) from [] (kgdb_arch_set_breakpoint+0x40/0x4c)
  (kgdb_arch_set_breakpoint) from [] (kgdb_validate_break_address+0x2c/0x60)
  (kgdb_validate_break_address) from [] (dbg_set_sw_break+0x1c/0xdc)
  (dbg_set_sw_break) from [] (gdb_serial_stub+0x9c4/0xba4)
  (gdb_serial_stub) from [] (kgdb_cpu_enter+0x1f8/0x60c)
  (kgdb_cpu_enter) from [] (kgdb_handle_exception+0x19c/0x1d0)
  (kgdb_handle_exception) from [] (kgdb_compiled_brk_fn+0x30/0x3c)
  (kgdb_compiled_brk_fn) from [] (do_undefinstr+0x1a4/0x20c)
  (do_undefinstr) from [] (__und_svc_finish+0x0/0x34)

It turns out that when we're in kgdb all the CPUs are stopped anyway
so there's no reason we should be calling patch_text().  We can
instead directly call __patch_text() which assumes that CPUs have
already been stopped.

Fixes: 23a4e4050ba9 ("arm: kgdb: Handle read-only text / modules")
Reported-by: Aapo Vienamo 
Signed-off-by: Douglas Anderson 
Reviewed-by: Stephen Boyd 
Acked-by: Kees Cook 
Signed-off-by: Russell King 
Signed-off-by: Greg Kroah-Hartman

ARM: fix Thumb2 signal handling when ARMv6 is enabled

2015-10-22T21:43:12+00:00

commit 9b55613f42e8d40d5c9ccb8970bde6af4764b2ab upstream.

When a kernel is built covering ARMv6 to ARMv7, we omit to clear the
IT state when entering a signal handler.  This can cause the first
few instructions to be conditionally executed depending on the parent
context.

In any case, the original test for >= ARMv7 is broken - ARMv6 can have
Thumb-2 support as well, and an ARMv6T2 specific build would omit this
code too.

Relax the test back to ARMv6 or greater.  This results in us always
clearing the IT state bits in the PSR, even on CPUs where these bits
are reserved.  However, they're reserved for the IT state, so this
should cause no harm.

Fixes: d71e1352e240 ("Clear the IT state when invoking a Thumb-2 signal handler")
Acked-by: Tony Lindgren 
Tested-by: H. Nikolaus Schaller 
Tested-by: Grazvydas Ignotas 
Signed-off-by: Russell King 
Signed-off-by: Greg Kroah-Hartman

ARM: 8393/1: smp: Fix suspicious RCU usage with ipi tracepoints

2015-08-03T16:29:19+00:00

commit 398f74569cebbf06bc6b069442bcd0e9616ca465 upstream.

John Stultz reports an RCU splat on boot with ARM ipi trace
events enabled.

===============================
[ INFO: suspicious RCU usage. ]
4.1.0-rc7-00033-gb5bed2f #153 Not tainted
-------------------------------
include/trace/events/ipi.h:68 suspicious rcu_dereference_check() usage!

other info that might help us debug this:

RCU used illegally from idle CPU!
rcu_scheduler_active = 1, debug_locks = 0
RCU used illegally from extended quiescent state!
no locks held by swapper/0/0.

stack backtrace:
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.1.0-rc7-00033-gb5bed2f #153
Hardware name: Qualcomm (Flattened Device Tree)
[] (unwind_backtrace) from [] (show_stack+0x10/0x14)
[] (show_stack) from [] (dump_stack+0x70/0xbc)
[] (dump_stack) from [] (handle_IPI+0x428/0x604)
[] (handle_IPI) from [] (gic_handle_irq+0x54/0x5c)
[] (gic_handle_irq) from [] (__irq_svc+0x44/0x7c)
Exception stack(0xc09f3f48 to 0xc09f3f90)
3f40:                   00000001 00000001 00000000 c09f73b8 c09f4528 c0a5de9c
3f60: c076b4f0 00000000 00000000 c09ef108 c0a5cec1 00000001 00000000 c09f3f90
3f80: c026bf60 c0210ab8 20000113 ffffffff
[] (__irq_svc) from [] (arch_cpu_idle+0x20/0x3c)
[] (arch_cpu_idle) from [] (cpu_startup_entry+0x2c0/0x5dc)
[] (cpu_startup_entry) from [] (start_kernel+0x358/0x3c4)
[] (start_kernel) from [<8020807c>] (0x8020807c)

At this point in the IPI handling path we haven't called
irq_enter() yet, so RCU doesn't know that we're about to exit
idle and properly warns that we're using RCU from an idle CPU.
Use trace_ipi_entry_rcuidle() instead of trace_ipi_entry() so
that RCU is informed about our exit from idle.

Fixes: 365ec7b17327 ("ARM: add IPI tracepoints")
Reported-by: John Stultz 
Tested-by: John Stultz 
Acked-by: Steven Rostedt 
Reviewed-by: Paul E. McKenney 
Signed-off-by: Stephen Boyd 
Signed-off-by: Russell King 
Signed-off-by: Greg Kroah-Hartman

ARM: 8357/1: perf: fix memory leak when probing PMU PPIs

2015-05-18T20:51:28+00:00

Commit 338d9dd3e2ae ("ARM: 8351/1: perf: don't warn about missing
interrupt-affinity property for PPIs") added a check for PPIs so that
we avoid parsing the interrupt-affinity property for these naturally
affine interrupts.

Unfortunately, this check can trigger an early (successful) return and
we will leak the irqs array. This patch fixes the issue by reordering
the code so that the check is performed before any independent
allocation.

Reported-by: David Binderman 
Signed-off-by: Will Deacon 
Signed-off-by: Russell King

ARM: fix missing syscall trace exit

2015-05-15T10:06:35+00:00

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

ARM: 8352/1: perf: Fix the pmu node name in warning message

2015-05-03T22:23:44+00:00

With commit 9fd85eb502a7 ("ARM: pmu: add support for interrupt-affinity
property"), we print a warning when we find a PMU SPI with a missing
missing interrupt-affinity property in a pmu node. Unfortunately, we
pass the wrong (NULL) device node to of_node_full_name, resulting in
unhelpful messages such as:

 hw perfevents: Failed to parse /interrupt-affinity[0]

This patch fixes the name to that of the pmu node.

Fixes: 9fd85eb502a7 (ARM: pmu: add support for interrupt-affinity property)

Acked-by: Mark Rutland 
Signed-off-by: Will Deacon 
Signed-off-by: Russell King