linux-stable.git/arch/arm/kernel, branch linux-3.16.y

jump_label: Rename JUMP_LABEL_{EN,DIS}ABLE to JUMP_LABEL_{JMP,NOP}

2019-05-22T22:15:03+00:00

commit 76b235c6bcb16062d663e2ee96db0b69f2e6bc14 upstream.

Since we've already stepped away from ENABLE is a JMP and DISABLE is a
NOP with the branch_default bits, and are going to make it even worse,
rename it to make it all clearer.

This way we don't mix multiple levels of logic attributes, but have a
plain 'physical' name for what the current instruction patching status
of a jump label is.

This is a first step in removing the naming confusion that has led to
a stream of avoidable bugs such as:

  a833581e372a ("x86, perf: Fix static_key bug in load_mm_cr4()")

Signed-off-by: Peter Zijlstra (Intel) 
Cc: Andrew Morton 
Cc: Linus Torvalds 
Cc: Paul E. McKenney 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: linux-kernel@vger.kernel.org
[ Beefed up the changelog. ]
Signed-off-by: Ingo Molnar 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings

ARM: 8771/1: kprobes: Prohibit kprobes on do_undefinstr

2018-10-21T07:46:14+00:00

commit eb0146daefdde65665b7f076fbff7b49dade95b9 upstream.

Prohibit kprobes on do_undefinstr because kprobes on
arm is implemented by undefined instruction. This means
if we probe do_undefinstr(), it can cause infinit
recursive exception.

Fixes: 24ba613c9d6c ("ARM kprobes: core code")
Signed-off-by: Masami Hiramatsu 
Signed-off-by: Russell King 
Signed-off-by: Ben Hutchings

ARM: 8720/1: ensure dump_instr() checks addr_limit

2018-01-01T20:52:05+00:00

commit b9dd05c7002ee0ca8b676428b2268c26399b5e31 upstream.

When CONFIG_DEBUG_USER is enabled, it's possible for a user to
deliberately trigger dump_instr() with a chosen kernel address.

Let's avoid problems resulting from this by using get_user() rather than
__get_user(), ensuring that we don't erroneously access kernel memory.

So that we can use the same code to dump user instructions and kernel
instructions, the common dumping code is factored out to __dump_instr(),
with the fs manipulated appropriately in dump_instr() around calls to
this.

Signed-off-by: Mark Rutland 
Signed-off-by: Russell King 
Signed-off-by: Ben Hutchings

ARM: 8160/1: drop warning about return_address not using unwind tables

2017-11-11T13:33:59+00:00

commit e16343c47e4276f5ebc77ca16feb5e50ca1918f9 upstream.

The warning was introduced in 2009 (commit 4bf1fa5a34aa ([ARM] 5613/1:
implement CALLER_ADDRESSx)). The only "problem" here is that
CALLER_ADDRESSx for x > 1 returns NULL which doesn't do much harm.

The drawback of implementing a fix (i.e. use unwind tables to implement CALLER_ADDRESSx) is that much of the unwinder code would need to be marked as not
traceable.

Signed-off-by: Uwe Kleine-König 
Signed-off-by: Russell King 
Signed-off-by: Arnd Bergmann 
Signed-off-by: Ben Hutchings

ARM: 8452/3: PJ4: make coprocessor access sequences buildable in Thumb2 mode

2017-11-11T13:33:58+00:00

commit 5008efc83bf85b647aa1cbc44718b1675bbb7444 upstream.

The PJ4 inline asm sequence to write to cp15 cannot be built in Thumb-2
mode, due to the way it performs arithmetic on the program counter, so it
is built in ARM mode instead. However, building C files in ARM mode under
CONFIG_THUMB2_KERNEL is problematic, since the instrumentation performed
by subsystems like ftrace does not expect having to deal with interworking
branches.

Since the sequence in question is simply a poor man's ISB instruction,
let's use a straight 'isb' instead when building in Thumb2 mode. Thumb2
implies V7, so 'isb' should always be supported in that case.

Acked-by: Arnd Bergmann 
Acked-by: Nicolas Pitre 
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Russell King 
Signed-off-by: Arnd Bergmann 
Signed-off-by: Ben Hutchings

ARM: 8221/1: PJ4: allow building in Thumb-2 mode

2017-11-11T13:33:58+00:00

commit 13d1b9575ac2c2da143cd2236b6cf0fc314570f8 upstream.

Two files that get included when building the multi_v7_defconfig target
fail to build when selecting THUMB2_KERNEL for this configuration.

In both cases, we can just build the file as ARM code, as none of its
symbols are exported to modules, so there are no interworking concerns.
In the iwmmxt.S case, add ENDPROC() declarations so the symbols are
annotated as functions, resulting in the linker to emit the appropriate
mode switches.

Acked-by: Nicolas Pitre 
Tested-by: Olof Johansson 
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Russell King 
Signed-off-by: Arnd Bergmann 
Signed-off-by: Ben Hutchings

ARM: kexec: fix failure to boot crash kernel

2017-11-11T13:33:02+00:00

commit 0d70262a2d60886da6fe5b1fc8bbcd76cbbc306d upstream.

When kexec was converted to DTB, the dtb address was passed between
machine_kexec_prepare() and machine_kexec() using a static variable.
This is bad news if you load a crash kernel followed by a normal
kernel or vice versa - the last loaded kernel overwrites the dtb
address.

This can result in kexec failures, as (eg) we try to boot the crash
kernel with the last loaded dtb.  For example, with:

the crash kernel fails to find the dtb.

Avoid this by defining a kimage architecture structure, and store
the address to be passed in r2 there, which will either be the ATAGs
or the dtb blob.

Fixes: 4cabd1d9625c ("ARM: 7539/1: kexec: scan for dtb magic in segments")
Fixes: 42d720d1731a ("ARM: kexec: Make .text R/W in machine_kexec")
Reported-by: Keerthy 
Tested-by: Keerthy 
Signed-off-by: Russell King 
Signed-off-by: Ben Hutchings

ARM: kexec: Make .text R/W in machine_kexec

2017-11-11T13:33:01+00:00

commit 42d720d1731a9d7035c2812437c35e271ec4dd78 upstream.

With the introduction of Kees Cook's patch to make the kernel .text
read-only the existing method by which kexec works got broken since it
directly pokes some values in the template code, which resides in the
.text section.

The current patch changes the way those values are inserted so that poking
.text section occurs only in machine_kexec (e.g when we are about to nuke
the old kernel and are beyond the point of return). This allows to use
set_kernel_text_rw() to directly patch the values in the .text section.

I had already sent a patch which achieved this but it was significantly
more complicated, so this is a cleaner/straight-forward approach.

Signed-off-by: Nikolay Borisov 
Acked-by: Will Deacon 
[kees: collapsed kexec_boot_atags (will.daecon)]
[kees: for bisectability, moved set_kernel_text_rw() to RODATA patch]
Signed-off-by: Kees Cook 
Acked-by: Nicolas Pitre 
Signed-off-by: Ben Hutchings

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

2017-03-16T02:27:08+00:00

commit 228dbbfb5d77f8e047b2a1d78da14b7158433027 upstream.

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

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: Ben Hutchings

ARM: 8634/1: hw_breakpoint: blacklist Scorpion CPUs

2017-03-16T02:26:55+00:00

commit ddc37832a1349f474c4532de381498020ed71d31 upstream.

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 
Signed-off-by: Russell King 
[bwh: Backported to 3.16: open-code read_cpuid_part()]
Signed-off-by: Ben Hutchings