linux-stable.git/arch/arm/include/asm, branch v3.18.76

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

2017-08-11T16:30:16+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 
Signed-off-by: Greg Kroah-Hartman

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

2017-04-22T05:14:58+00:00

This reverts commit dbcfee724255ae171af51aaa56d8c5b78342adc9 which is
commit be95485a0b8288a93402705730d3ea32f9f812b9 upstream.

Upstream commit be95485 (ARM: 8457/1: psci-smp is built only for SMP)
was intended to fix the build error for configs with CONFIG_SMP=n and
CONFIG_ARM_PSCI=y, but it end up introducing a build error when
cherry-picked on 3.18.y.

This patch resulted in redefinition of psci_init() and broke the
build for every build config in 3.18.y with CONFIG_SMP=n and
CONFIG_ARM_PSCI=y.

Signed-off-by: Amit Pundir 
Signed-off-by: Greg Kroah-Hartman

ARM: 8584/1: floppy: avoid gcc-6 warning

2017-04-18T05:55:45+00:00

commit dd665be0e243873343a28e18f9f345927b658daf upstream.

gcc-6.0 warns about comparisons between two identical expressions,
which is what we get in the floppy driver when writing to the FD_DOR
register:

drivers/block/floppy.c: In function 'set_dor':
drivers/block/floppy.c:810:44: error: self-comparison always evaluates to true [-Werror=tautological-compare]
   fd_outb(newdor, FD_DOR);

It would be nice to use a static inline function instead of the
macro, to avoid the warning, but we cannot do that because the
FD_DOR definition is incomplete at this point.

Adding a cast to (u32) is a harmless way to shut up the warning,
just not very nice.

Signed-off-by: Arnd Bergmann 
Signed-off-by: Russell King 
Signed-off-by: Greg Kroah-Hartman

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

2016-12-23T14:41:28+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: 8579/1: mm: Fix definition of pmd_mknotpresent

2016-07-11T15:15:55+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-11T15:11:03+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-12T21:06:25+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

ARM: 8320/1: fix integer overflow in ELF_ET_DYN_BASE

2015-05-17T23:11:57+00:00

[ Upstream commit 8defb3367fcd19d1af64c07792aade0747b54e0f ]

Usually ELF_ET_DYN_BASE is 2/3 of TASK_SIZE. With 3G/1G user/kernel
split this is not so, because 2*TASK_SIZE overflows 32 bits,
so the actual value of ELF_ET_DYN_BASE is:
	(2 * TASK_SIZE / 3) = 0x2a000000

When ASLR is disabled PIE binaries will load at ELF_ET_DYN_BASE address.
On 32bit platforms AddressSanitzer uses addresses [0x20000000 - 0x40000000]
for shadow memory [1]. So ASan doesn't work for PIE binaries when ASLR disabled
as it fails to map shadow memory.
Also after Kees's 'split ET_DYN ASLR from mmap ASLR' patchset PIE binaries
has a high chance of loading somewhere in between [0x2a000000 - 0x40000000]
even if ASLR enabled. This makes ASan with PIE absolutely incompatible.

Fix overflow by dividing TASK_SIZE prior to multiplying.
After this patch ELF_ET_DYN_BASE equals to (for CONFIG_VMSPLIT_3G=y):
	(TASK_SIZE / 3 * 2) = 0x7f555554

[1] https://code.google.com/p/address-sanitizer/wiki/AddressSanitizerAlgorithm#Mapping

Signed-off-by: Andrey Ryabinin 
Reported-by: Maria Guseva 
Cc: stable@vger.kernel.org
Signed-off-by: Russell King 
Signed-off-by: Sasha Levin

arm64: KVM: Do not use pgd_index to index stage-2 pgd

2015-05-11T11:07:37+00:00

commit 04b8dc85bf4a64517e3cf20e409eeaa503b15cc1 upstream.

The kernel's pgd_index macro is designed to index a normal, page
sized array. KVM is a bit diffferent, as we can use concatenated
pages to have a bigger address space (for example 40bit IPA with
4kB pages gives us an 8kB PGD.

In the above case, the use of pgd_index will always return an index
inside the first 4kB, which makes a guest that has memory above
0x8000000000 rather unhappy, as it spins forever in a page fault,
whist the host happilly corrupts the lower pgd.

The obvious fix is to get our own kvm_pgd_index that does the right
thing(tm).

Tested on X-Gene with a hacked kvmtool that put memory at a stupidly
high address.

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

arm64: KVM: Fix stage-2 PGD allocation to have per-page refcounting

2015-05-11T11:07:36+00:00

commit a987370f8e7a1677ae385042644326d9cd145a20 upstream.

We're using __get_free_pages with to allocate the guest's stage-2
PGD. The standard behaviour of this function is to return a set of
pages where only the head page has a valid refcount.

This behaviour gets us into trouble when we're trying to increment
the refcount on a non-head page:

page:ffff7c00cfb693c0 count:0 mapcount:0 mapping:          (null) index:0x0
flags: 0x4000000000000000()
page dumped because: VM_BUG_ON_PAGE((*({ __attribute__((unused)) typeof((&page->_count)->counter) __var = ( typeof((&page->_count)->counter)) 0; (volatile typeof((&page->_count)->counter) *)&((&page->_count)->counter); })) <= 0)
BUG: failure at include/linux/mm.h:548/get_page()!
Kernel panic - not syncing: BUG!
CPU: 1 PID: 1695 Comm: kvm-vcpu-0 Not tainted 4.0.0-rc1+ #3825
Hardware name: APM X-Gene Mustang board (DT)
Call trace:
[] dump_backtrace+0x0/0x13c
[] show_stack+0x10/0x1c
[] dump_stack+0x74/0x94
[] panic+0x100/0x240
[] stage2_get_pmd+0x17c/0x2bc
[] kvm_handle_guest_abort+0x4b4/0x6b0
[] handle_exit+0x58/0x180
[] kvm_arch_vcpu_ioctl_run+0x114/0x45c
[] kvm_vcpu_ioctl+0x2e0/0x754
[] do_vfs_ioctl+0x424/0x5c8
[] SyS_ioctl+0x40/0x78
CPU0: stopping

A possible approach for this is to split the compound page using
split_page() at allocation time, and change the teardown path to
free one page at a time.  It turns out that alloc_pages_exact() and
free_pages_exact() does exactly that.

While we're at it, the PGD allocation code is reworked to reduce
duplication.

This has been tested on an X-Gene platform with a 4kB/48bit-VA host
kernel, and kvmtool hacked to place memory in the second page of
the hardware PGD (PUD for the host kernel). Also regression-tested
on a Cubietruck (Cortex-A7).

 [ Reworked to use alloc_pages_exact() and free_pages_exact() and to
   return pointers directly instead of by reference as arguments
    - Christoffer ]

Reported-by: Mark Rutland 
Signed-off-by: Marc Zyngier 
Signed-off-by: Christoffer Dall 
Signed-off-by: Shannon Zhao 
Signed-off-by: Sasha Levin