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

ARM: 8632/1: ftrace: fix syscall name matching

2017-09-10T20:36:06+00:00

[ Upstream commit 270c8cf1cacc69cb8d99dea812f06067a45e4609 ]

ARM has a few system calls (most notably mmap) for which the names of
the functions which are referenced in the syscall table do not match the
names of the syscall tracepoints.  As a consequence of this, these
tracepoints are not made available.  Implement
arch_syscall_match_sym_name to fix this and allow tracing even these
system calls.

Signed-off-by: Rabin Vincent 
Signed-off-by: Russell King 
Signed-off-by: Sasha Levin

arm: move ELF_ET_DYN_BASE to 4MB

2017-07-31T17:37:55+00:00

[ Upstream commit 6a9af90a3bcde217a1c053e135f5f43e5d5fafbd ]

Now that explicitly executed loaders are loaded in the mmap region, we
have more freedom to decide where we position PIE binaries in the
address space to avoid possible collisions with mmap or stack regions.

4MB is chosen here mainly to have parity with x86, where this is the
traditional minimum load location, likely to avoid historically
requiring a 4MB page table entry when only a portion of the first 4MB
would be used (since the NULL address is avoided).

For ARM the position could be 0x8000, the standard ET_EXEC load address,
but that is needlessly close to the NULL address, and anyone running PIE
on 32-bit ARM will have an MMU, so the tight mapping is not needed.

Link: http://lkml.kernel.org/r/1498154792-49952-2-git-send-email-keescook@chromium.org
Signed-off-by: Kees Cook 
Cc: Russell King 
Cc: Catalin Marinas 
Cc: Will Deacon 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Michael Ellerman 
Cc: Martin Schwidefsky 
Cc: Heiko Carstens 
Cc: James Hogan 
Cc: Pratyush Anand 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: Alexander Viro 
Cc: Andy Lutomirski 
Cc: Daniel Micay 
Cc: Dmitry Safonov 
Cc: Grzegorz Andrejczuk 
Cc: Kees Cook 
Cc: Masahiro Yamada 
Cc: Qualys Security Advisory 
Cc: Rik van Riel 
Cc: Thomas Gleixner 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Sasha Levin

kvm arm: Move fake PGD handling to arch specific files

2017-06-08T10:12:19+00:00

[ Upstream commit 120f0779c3ed89c25ef1db943feac8ed73a0d7f9 ]

Rearrange the code for fake pgd handling, which is applicable
only for arm64. This will later be removed once we introduce
the stage2 page table walker macros.

Reviewed-by: Marc Zyngier 
Reviewed-by: Christoffer Dall 
Signed-off-by: Suzuki K Poulose 
Signed-off-by: Sasha Levin

arm/arm64: KVM: Enforce unconditional flush to PoC when mapping to stage-2

2017-05-17T19:06:58+00:00

[ Upstream commit 8f36ebaf21fdae99c091c67e8b6fab33969f2667 ]

When we fault in a page, we flush it to the PoC (Point of Coherency)
if the faulting vcpu has its own caches off, so that it can observe
the page we just brought it.

But if the vcpu has its caches on, we skip that step. Bad things
happen when *another* vcpu tries to access that page with its own
caches disabled. At that point, there is no garantee that the
data has made it to the PoC, and we access stale data.

The obvious fix is to always flush to PoC when a page is faulted
in, no matter what the state of the vcpu is.

Cc: stable@vger.kernel.org
Fixes: 2d58b733c876 ("arm64: KVM: force cache clean on page fault when caches are off")
Reviewed-by: Christoffer Dall 
Signed-off-by: Marc Zyngier 
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

ARM: 8617/1: dma: fix dma_max_pfn()

2016-12-22T03:45:42+00:00

[ Upstream commit d248220f0465b818887baa9829e691fe662b2c5e ]

Since commit 6ce0d2001692 ("ARM: dma: Use dma_pfn_offset for dma address translation"),
dma_to_pfn() already returns the PFN with the physical memory start offset
so we don't need to add it again.

This fixes USB mass storage lock-up problem on systems that can't do DMA
over the entire physical memory range (e.g.) Keystone 2 systems with 4GB RAM
can only do DMA over the first 2GB. [K2E-EVM].

What happens there is that without this patch SCSI layer sets a wrong
bounce buffer limit in scsi_calculate_bounce_limit() for the USB mass
storage device. dma_max_pfn() evaluates to 0x8fffff and bounce_limit
is set to 0x8fffff000 whereas maximum DMA'ble physical memory on Keystone 2
is 0x87fffffff. This results in non DMA'ble pages being given to the
USB controller and hence the lock-up.

NOTE: in the above case, USB-SCSI-device's dma_pfn_offset was showing as 0.
This should have really been 0x780000 as on K2e, LOWMEM_START is 0x80000000
and HIGHMEM_START is 0x800000000. DMA zone is 2GB so dma_max_pfn should be
0x87ffff. The incorrect dma_pfn_offset for the USB storage device is because
USB devices are not correctly inheriting the dma_pfn_offset from the
USB host controller. This will be fixed by a separate patch.

Fixes: 6ce0d2001692 ("ARM: dma: Use dma_pfn_offset for dma address translation")
Cc: stable@vger.kernel.org
Cc: Greg Kroah-Hartman 
Cc: Santosh Shilimkar 
Cc: Arnd Bergmann 
Cc: Olof Johansson 
Cc: Catalin Marinas 
Cc: Linus Walleij 
Reported-by: Grygorii Strashko 
Signed-off-by: Roger Quadros 
Signed-off-by: Russell King 
Signed-off-by: Sasha Levin

arm/arm64: KVM: Handle out-of-RAM cache maintenance as a NOP

2016-11-24T01:59:49+00:00

[ Upstream commit 57c841f131ef295b583365d2fddd6b0d16e82c10 ]

So far, our handling of cache maintenance by VA has been pretty
simple: Either the access is in the guest RAM and generates a S2
fault, which results in the page being mapped RW, or we go down
the io_mem_abort() path, and nuke the guest.

The first one is fine, but the second one is extremely weird.
Treating the CM as an I/O is wrong, and nothing in the ARM ARM
indicates that we should generate a fault for something that
cannot end-up in the cache anyway (even if the guest maps it,
it will keep on faulting at stage-2 for emulation).

So let's just skip this instruction, and let the guest get away
with it.

Reviewed-by: Christoffer Dall 
Signed-off-by: Marc Zyngier 
Signed-off-by: Sasha Levin

ARM: 8579/1: mm: Fix definition of pmd_mknotpresent

2016-07-11T00:19:54+00:00

[ Upstream commit 56530f5d2ddc9b9fade7ef8db9cb886e9dc689b5 ]

Currently pmd_mknotpresent will use a zero entry to respresent an
invalidated pmd.

Unfortunately this definition clashes with pmd_none, thus it is
possible for a race condition to occur if zap_pmd_range sees pmd_none
whilst __split_huge_pmd_locked is running too with pmdp_invalidate
just called.

This patch fixes the race condition by modifying pmd_mknotpresent to
create non-zero faulting entries (as is done in other architectures),
removing the ambiguity with pmd_none.

[catalin.marinas@arm.com: using L_PMD_SECT_VALID instead of PMD_TYPE_SECT]

Fixes: 8d9625070073 ("ARM: mm: Transparent huge page support for LPAE systems.")
Cc:  # 3.11+
Reported-by: Kirill A. Shutemov 
Acked-by: Will Deacon 
Cc: Russell King 
Signed-off-by: Steve Capper 
Signed-off-by: Catalin Marinas 
Signed-off-by: Russell King 
Signed-off-by: Sasha Levin

ARM: 8578/1: mm: ensure pmd_present only checks the valid bit

2016-07-11T00:19:54+00:00

[ Upstream commit 624531886987f0f1b5d01fb598034d039198e090 ]

In a subsequent patch, pmd_mknotpresent will clear the valid bit of the
pmd entry, resulting in a not-present entry from the hardware's
perspective. Unfortunately, pmd_present simply checks for a non-zero pmd
value and will therefore continue to return true even after a
pmd_mknotpresent operation. Since pmd_mknotpresent is only used for
managing huge entries, this is only an issue for the 3-level case.

This patch fixes the 3-level pmd_present implementation to take into
account the valid bit. For bisectability, the change is made before the
fix to pmd_mknotpresent.

[catalin.marinas@arm.com: comment update regarding pmd_mknotpresent patch]

Fixes: 8d9625070073 ("ARM: mm: Transparent huge page support for LPAE systems.")
Cc:  # 3.11+
Cc: Russell King 
Cc: Steve Capper 
Signed-off-by: Will Deacon 
Signed-off-by: Catalin Marinas 
Signed-off-by: Russell King 
Signed-off-by: Sasha Levin

ARM: 8457/1: psci-smp is built only for SMP

2016-04-12T02:44:21+00:00

[ Upstream commit be95485a0b8288a93402705730d3ea32f9f812b9 ]

The PSCI SMP implementation is built only when both CONFIG_SMP and
CONFIG_ARM_PSCI are set, so a configuration that has the latter
but not the former can get a link error when it tries to call
psci_smp_available().

arch/arm/mach-tegra/built-in.o: In function `tegra114_cpuidle_init':
cpuidle-tegra114.c:(.init.text+0x52a): undefined reference to `psci_smp_available'

This corrects the #ifdef in the psci.h header file to match the
Makefile conditional we have for building that function.

Signed-off-by: Arnd Bergmann 
Signed-off-by: Russell King 
Signed-off-by: Sasha Levin