linux.git/arch/arm64/kernel, branch v5.4.64

KVM: arm64: Add kvm_extable for vaxorcism code

2020-09-05T09:22:50+00:00

commit e9ee186bb735bfc17fa81dbc9aebf268aee5b41e upstream.

KVM has a one instruction window where it will allow an SError exception
to be consumed by the hypervisor without treating it as a hypervisor bug.
This is used to consume asynchronous external abort that were caused by
the guest.

As we are about to add another location that survives unexpected exceptions,
generalise this code to make it behave like the host's extable.

KVM's version has to be mapped to EL2 to be accessible on nVHE systems.

The SError vaxorcism code is a one instruction window, so has two entries
in the extable. Because the KVM code is copied for VHE and nVHE, we end up
with four entries, half of which correspond with code that isn't mapped.

Cc:  # 5.4.x
Signed-off-by: James Morse 
Reviewed-by: Marc Zyngier 
Signed-off-by: Catalin Marinas 
Signed-off-by: Andre Przywara 
Signed-off-by: Greg Kroah-Hartman

arm64: Allow booting of late CPUs affected by erratum 1418040

2020-09-03T09:27:01+00:00

[ Upstream commit bf87bb0881d0f59181fe3bbcf29c609f36483ff8 ]

As we can now switch from a system that isn't affected by 1418040
to a system that globally is affected, let's allow affected CPUs
to come in at a later time.

Signed-off-by: Marc Zyngier 
Tested-by: Sai Prakash Ranjan 
Reviewed-by: Stephen Boyd 
Reviewed-by: Suzuki K Poulose 
Acked-by: Will Deacon 
Link: https://lore.kernel.org/r/20200731173824.107480-3-maz@kernel.org
Signed-off-by: Catalin Marinas 
Signed-off-by: Sasha Levin

arm64: Move handling of erratum 1418040 into C code

2020-09-03T09:27:01+00:00

[ Upstream commit d49f7d7376d0c0daf8680984a37bd07581ac7d38 ]

Instead of dealing with erratum 1418040 on each entry and exit,
let's move the handling to __switch_to() instead, which has
several advantages:

- It can be applied when it matters (switching between 32 and 64
  bit tasks).
- It is written in C (yay!)
- It can rely on static keys rather than alternatives

Signed-off-by: Marc Zyngier 
Tested-by: Sai Prakash Ranjan 
Reviewed-by: Stephen Boyd 
Acked-by: Will Deacon 
Link: https://lore.kernel.org/r/20200731173824.107480-2-maz@kernel.org
Signed-off-by: Catalin Marinas 
Signed-off-by: Sasha Levin

arm64: Fix __cpu_logical_map undefined issue

2020-09-03T09:26:49+00:00

[ Upstream commit eaecca9e7710281be7c31d892c9f447eafd7ddd9 ]

The __cpu_logical_map undefined issue occued when the new
tegra194-cpufreq drvier building as a module.

ERROR: modpost: "__cpu_logical_map" [drivers/cpufreq/tegra194-cpufreq.ko] undefined!

The driver using cpu_logical_map() macro which will expand to
__cpu_logical_map, we can't access it in a drvier. Let's turn
cpu_logical_map() into a C wrapper and export it to fix the
build issue.

Also create a function set_cpu_logical_map(cpu, hwid) when assign
a value to cpu_logical_map(cpu).

Reported-by: Hulk Robot 
Signed-off-by: Kefeng Wang 
Signed-off-by: Catalin Marinas 
Signed-off-by: Sasha Levin

ARM64: vdso32: Install vdso32 from vdso_install

2020-08-26T08:41:05+00:00

[ Upstream commit 8d75785a814241587802655cc33e384230744f0c ]

Add the 32-bit vdso Makefile to the vdso_install rule so that 'make
vdso_install' installs the 32-bit compat vdso when it is compiled.

Fixes: a7f71a2c8903 ("arm64: compat: Add vDSO")
Signed-off-by: Stephen Boyd 
Reviewed-by: Vincenzo Frascino 
Acked-by: Will Deacon 
Cc: Vincenzo Frascino 
Link: https://lore.kernel.org/r/20200818014950.42492-1-swboyd@chromium.org
Signed-off-by: Catalin Marinas 
Signed-off-by: Sasha Levin

arm64: perf: Correct the event index in sysfs

2020-08-21T11:05:23+00:00

commit 539707caa1a89ee4efc57b4e4231c20c46575ccc upstream.

When PMU event ID is equal or greater than 0x4000, it will be reduced
by 0x4000 and it is not the raw number in the sysfs. Let's correct it
and obtain the raw event ID.

Before this patch:
cat /sys/bus/event_source/devices/armv8_pmuv3_0/events/sample_feed
event=0x001
After this patch:
cat /sys/bus/event_source/devices/armv8_pmuv3_0/events/sample_feed
event=0x4001

Signed-off-by: Shaokun Zhang 
Cc: Will Deacon 
Cc: Mark Rutland 
Cc: 
Link: https://lore.kernel.org/r/1592487344-30555-3-git-send-email-zhangshaokun@hisilicon.com
[will: fixed formatting of 'if' condition]
Signed-off-by: Will Deacon 
Signed-off-by: Greg Kroah-Hartman

arm64: Use test_tsk_thread_flag() for checking TIF_SINGLESTEP

2020-07-29T08:18:40+00:00

[ Upstream commit 5afc78551bf5d53279036e0bf63314e35631d79f ]

Rather than open-code test_tsk_thread_flag() at each callsite, simply
replace the couple of offenders with calls to test_tsk_thread_flag()
directly.

Signed-off-by: Will Deacon 
Signed-off-by: Sasha Levin

arm64: compat: Ensure upper 32 bits of x0 are zero on syscall return

2020-07-22T07:33:16+00:00

commit 15956689a0e60aa0c795174f3c310b60d8794235 upstream.

Although we zero the upper bits of x0 on entry to the kernel from an
AArch32 task, we do not clear them on the exception return path and can
therefore expose 64-bit sign extended syscall return values to userspace
via interfaces such as the 'perf_regs' ABI, which deal exclusively with
64-bit registers.

Explicitly clear the upper 32 bits of x0 on return from a compat system
call.

Cc: 
Cc: Mark Rutland 
Cc: Keno Fischer 
Cc: Luis Machado 
Signed-off-by: Will Deacon 
Signed-off-by: Greg Kroah-Hartman

arm64: ptrace: Consistently use pseudo-singlestep exceptions

2020-07-22T07:33:16+00:00

commit ac2081cdc4d99c57f219c1a6171526e0fa0a6fff upstream.

Although the arm64 single-step state machine can be fast-forwarded in
cases where we wish to generate a SIGTRAP without actually executing an
instruction, this has two major limitations outside of simply skipping
an instruction due to emulation.

1. Stepping out of a ptrace signal stop into a signal handler where
   SIGTRAP is blocked. Fast-forwarding the stepping state machine in
   this case will result in a forced SIGTRAP, with the handler reset to
   SIG_DFL.

2. The hardware implicitly fast-forwards the state machine when executing
   an SVC instruction for issuing a system call. This can interact badly
   with subsequent ptrace stops signalled during the execution of the
   system call (e.g. SYSCALL_EXIT or seccomp traps), as they may corrupt
   the stepping state by updating the PSTATE for the tracee.

Resolve both of these issues by injecting a pseudo-singlestep exception
on entry to a signal handler and also on return to userspace following a
system call.

Cc: 
Cc: Mark Rutland 
Tested-by: Luis Machado 
Reported-by: Keno Fischer 
Signed-off-by: Will Deacon 
Signed-off-by: Greg Kroah-Hartman

arm64: ptrace: Override SPSR.SS when single-stepping is enabled

2020-07-22T07:33:16+00:00

commit 3a5a4366cecc25daa300b9a9174f7fdd352b9068 upstream.

Luis reports that, when reverse debugging with GDB, single-step does not
function as expected on arm64:

  | I've noticed, under very specific conditions, that a PTRACE_SINGLESTEP
  | request by GDB won't execute the underlying instruction. As a consequence,
  | the PC doesn't move, but we return a SIGTRAP just like we would for a
  | regular successful PTRACE_SINGLESTEP request.

The underlying problem is that when the CPU register state is restored
as part of a reverse step, the SPSR.SS bit is cleared and so the hardware
single-step state can transition to the "active-pending" state, causing
an unexpected step exception to be taken immediately if a step operation
is attempted.

In hindsight, we probably shouldn't have exposed SPSR.SS in the pstate
accessible by the GPR regset, but it's a bit late for that now. Instead,
simply prevent userspace from configuring the bit to a value which is
inconsistent with the TIF_SINGLESTEP state for the task being traced.

Cc: 
Cc: Mark Rutland 
Cc: Keno Fischer 
Link: https://lore.kernel.org/r/1eed6d69-d53d-9657-1fc9-c089be07f98c@linaro.org
Reported-by: Luis Machado 
Tested-by: Luis Machado 
Signed-off-by: Will Deacon 
Signed-off-by: Greg Kroah-Hartman