linux-stable.git/arch, branch v4.3.5

arm64: kernel: fix architected PMU registers unconditional access

2016-01-31T19:25:55+00:00

commit f436b2ac90a095746beb6729b8ee8ed87c9eaede upstream.

The Performance Monitors extension is an optional feature of the
AArch64 architecture, therefore, in order to access Performance
Monitors registers safely, the kernel should detect the architected
PMU unit presence through the ID_AA64DFR0_EL1 register PMUVer field
before accessing them.

This patch implements a guard by reading the ID_AA64DFR0_EL1 register
PMUVer field to detect the architected PMU presence and prevent accessing
PMU system registers if the Performance Monitors extension is not
implemented in the core.

Cc: Peter Maydell 
Cc: Mark Rutland 
Fixes: 60792ad349f3 ("arm64: kernel: enforce pmuserenr_el0 initialization and restore")
Signed-off-by: Lorenzo Pieralisi 
Reported-by: Guenter Roeck 
Tested-by: Guenter Roeck 
Signed-off-by: Will Deacon 
Signed-off-by: Greg Kroah-Hartman

arm64: KVM: Add workaround for Cortex-A57 erratum 834220

2016-01-31T19:25:55+00:00

commit 498cd5c32be6e32bc0f8efcad48ab094bb2bfdf3 upstream.

Cortex-A57 parts up to r1p2 can misreport Stage 2 translation faults
when a Stage 1 permission fault or device alignment fault should
have been reported.

This patch implements the workaround (which is to validate that the
Stage-1 translation actually succeeds) by using code patching.

Reviewed-by: Will Deacon 
Signed-off-by: Marc Zyngier 
Signed-off-by: Christoffer Dall 
Signed-off-by: Greg Kroah-Hartman

arm64: restore bogomips information in /proc/cpuinfo

2016-01-31T19:25:55+00:00

commit 92e788b749862ebe9920360513a718e5dd4da7a9 upstream.

As previously reported, some userspace applications depend on bogomips
showed by /proc/cpuinfo. Although there is much less legacy impact on
aarch64 than arm, it does break libvirt.

This patch reverts commit 326b16db9f69 ("arm64: delay: don't bother
reporting bogomips in /proc/cpuinfo"), but with some tweak due to
context change and without the pr_info().

Fixes: 326b16db9f69 ("arm64: delay: don't bother reporting bogomips in /proc/cpuinfo")
Signed-off-by: Yang Shi 
Acked-by: Will Deacon 
Cc:  # 3.12+
Signed-off-by: Catalin Marinas 
Signed-off-by: Greg Kroah-Hartman

mn10300: Select CONFIG_HAVE_UID16 to fix build failure

2016-01-31T19:25:55+00:00

commit c86576ea114a9a881cf7328dc7181052070ca311 upstream.

mn10300 builds fail with

fs/stat.c: In function 'cp_old_stat':
fs/stat.c:163:2: error: 'old_uid_t' undeclared

ipc/util.c: In function 'ipc64_perm_to_ipc_perm':
ipc/util.c:540:2: error: 'old_uid_t' undeclared

Select CONFIG_HAVE_UID16 and remove local definition of CONFIG_UID16
to fix the problem.

Fixes: fbc416ff8618 ("arm64: fix building without CONFIG_UID16")
Cc: Arnd Bergmann 
Acked-by: Arnd Bergmann 
Acked-by: Acked-by: David Howells 
Signed-off-by: Guenter Roeck 
Signed-off-by: Greg Kroah-Hartman

arm64: kernel: enforce pmuserenr_el0 initialization and restore

2016-01-31T19:25:54+00:00

commit 60792ad349f3c6dc5735aafefe5dc9121c79e320 upstream.

The pmuserenr_el0 register value is architecturally UNKNOWN on reset.
Current kernel code resets that register value iff the core pmu device is
correctly probed in the kernel. On platforms with missing DT pmu nodes (or
disabled perf events in the kernel), the pmu is not probed, therefore the
pmuserenr_el0 register is not reset in the kernel, which means that its
value retains the reset value that is architecturally UNKNOWN (system
may run with eg pmuserenr_el0 == 0x1, which means that PMU counters access
is available at EL0, which must be disallowed).

This patch adds code that resets pmuserenr_el0 on cold boot and restores
it on core resume from shutdown, so that the pmuserenr_el0 setup is
always enforced in the kernel.

Cc: Mark Rutland 
Signed-off-by: Lorenzo Pieralisi 
Signed-off-by: Will Deacon 
Signed-off-by: Greg Kroah-Hartman

arm64: mm: ensure that the zero page is visible to the page table walker

2016-01-31T19:25:54+00:00

commit 32d6397805d00573ce1fa55f408ce2bca15b0ad3 upstream.

In paging_init, we allocate the zero page, memset it to zero and then
point TTBR0 to it in order to avoid speculative fetches through the
identity mapping.

In order to guarantee that the freshly zeroed page is indeed visible to
the page table walker, we need to execute a dsb instruction prior to
writing the TTBR.

Signed-off-by: Will Deacon 
Signed-off-by: Greg Kroah-Hartman

arm64: Clear out any singlestep state on a ptrace detach operation

2016-01-31T19:25:54+00:00

commit 5db4fd8c52810bd9740c1240ebf89223b171aa70 upstream.

Make sure to clear out any ptrace singlestep state when a ptrace(2)
PTRACE_DETACH call is made on arm64 systems.

Otherwise, the previously ptraced task will die off with a SIGTRAP
signal if the debugger just previously singlestepped the ptraced task.

Signed-off-by: John Blackwood 
[will: added comment to justify why this is in the arch code]
Signed-off-by: Will Deacon 
Signed-off-by: Greg Kroah-Hartman

ARM/arm64: KVM: correct PTE uncachedness check

2016-01-31T19:25:54+00:00

commit 0de58f852875a0f0dcfb120bb8433e4e73c7803b upstream.

Commit e6fab5442345 ("ARM/arm64: KVM: test properly for a PTE's
uncachedness") modified the logic to test whether a HYP or stage-2
mapping needs flushing, from [incorrectly] interpreting the page table
attributes to [incorrectly] checking whether the PFN that backs the
mapping is covered by host system RAM. The PFN number is part of the
output of the translation, not the input, so we have to use pte_pfn()
on the contents of the PTE, not __phys_to_pfn() on the HYP virtual
address or stage-2 intermediate physical address.

Fixes: e6fab5442345 ("ARM/arm64: KVM: test properly for a PTE's uncachedness")
Tested-by: Pavel Fedin 
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Marc Zyngier 
Signed-off-by: Greg Kroah-Hartman

arm64: KVM: Fix AArch32 to AArch64 register mapping

2016-01-31T19:25:54+00:00

commit c0f0963464c24e034b858441205455bf2a5d93ad upstream.

When running a 32bit guest under a 64bit hypervisor, the ARMv8
architecture defines a mapping of the 32bit registers in the 64bit
space. This includes banked registers that are being demultiplexed
over the 64bit ones.

On exceptions caused by an operation involving a 32bit register, the
HW exposes the register number in the ESR_EL2 register. It was so
far understood that SW had to distinguish between AArch32 and AArch64
accesses (based on the current AArch32 mode and register number).

It turns out that I misinterpreted the ARM ARM, and the clue is in
D1.20.1: "For some exceptions, the exception syndrome given in the
ESR_ELx identifies one or more register numbers from the issued
instruction that generated the exception. Where the exception is
taken from an Exception level using AArch32 these register numbers
give the AArch64 view of the register."

Which means that the HW is already giving us the translated version,
and that we shouldn't try to interpret it at all (for example, doing
an MMIO operation from the IRQ mode using the LR register leads to
very unexpected behaviours).

The fix is thus not to perform a call to vcpu_reg32() at all from
vcpu_reg(), and use whatever register number is supplied directly.
The only case we need to find out about the mapping is when we
actively generate a register access, which only occurs when injecting
a fault in a guest.

Reviewed-by: Robin Murphy 
Signed-off-by: Marc Zyngier 
Signed-off-by: Christoffer Dall 
Signed-off-by: Greg Kroah-Hartman

ARM/arm64: KVM: test properly for a PTE's uncachedness

2016-01-31T19:25:53+00:00

commit e6fab54423450d699a09ec2b899473a541f61971 upstream.

The open coded tests for checking whether a PTE maps a page as
uncached use a flawed '(pte_val(xxx) & CONST) != CONST' pattern,
which is not guaranteed to work since the type of a mapping is
not a set of mutually exclusive bits

For HYP mappings, the type is an index into the MAIR table (i.e, the
index itself does not contain any information whatsoever about the
type of the mapping), and for stage-2 mappings it is a bit field where
normal memory and device types are defined as follows:

    #define MT_S2_NORMAL            0xf
    #define MT_S2_DEVICE_nGnRE      0x1

I.e., masking *and* comparing with the latter matches on the former,
and we have been getting lucky merely because the S2 device mappings
also have the PTE_UXN bit set, or we would misidentify memory mappings
as device mappings.

Since the unmap_range() code path (which contains one instance of the
flawed test) is used both for HYP mappings and stage-2 mappings, and
considering the difference between the two, it is non-trivial to fix
this by rewriting the tests in place, as it would involve passing
down the type of mapping through all the functions.

However, since HYP mappings and stage-2 mappings both deal with host
physical addresses, we can simply check whether the mapping is backed
by memory that is managed by the host kernel, and only perform the
D-cache maintenance if this is the case.

Signed-off-by: Ard Biesheuvel 
Tested-by: Pavel Fedin 
Reviewed-by: Christoffer Dall 
Signed-off-by: Christoffer Dall 
Signed-off-by: Greg Kroah-Hartman