commit 846a136881b8f73c1f74250bf6acfaa309cab1f2 upstream.

Michael Olbrich reported that his test program fails when built with
-O2 -mcpu=cortex-a8 -mfpu=neon, and a kernel which supports v6 and v7
CPUs:

volatile int x = 2;
volatile int64_t y = 2;

int main() {
	volatile int a = 0;
	volatile int64_t b = 0;
	while (1) {
		a = (a + x) % (1 << 30);
		b = (b + y) % (1 << 30);
		assert(a == b);
	}
}

and two instances are run.  When built for just v7 CPUs, this program
works fine.  It uses the "vadd.i64 d19, d18, d16" VFP instruction.

It appears that we do not save the high-16 double VFP registers across
context switches when the kernel is built for v6 CPUs.  Fix that.

Tested-By: Michael Olbrich <m.olbrich@pengutronix.de>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8ef102c6b4bc996ff96ca52b34775fe931ec90c9 upstream.

The syscall tracing patch introduces a compile bug in lttng-modules
when the latter calls syscall_get_nr(), similar to the following:

<path-to-linux>/arch/arm/include/asm/syscall.h:21:2: error: implicit declaration of function 'task_thread_info' [-Werror=implicit-function-declaration]

The issue is that we are using task_thread_info() in the
syscall_get_nr() function in asm/syscall.h, but not explicitly
including sched.h from this file, so we can expect this bug might
surface any time that syscall_get_nr() is called.

Explicitly including sched.h solves the problem.

Signed-off-by: Wade Farnsworth <wade_farnsworth@mentor.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

kcmp has appeared on x86, but has not been noticed because
checksyscalls.sh is broken at the moment.  Reserve ARM syscall 378
for this should we ever need it, and add an __IGNORE entry for this
unimplemented syscall.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

Pull ARM fixes from Russell King:
 "It's been a while...  so there's a little more here than normal.

  Mostly updates from Will for the breakpoint stuff, and plugging a few
  holes in the user access functions which crept in when domain support
  was disabled for ARMv7 CPUs."

* 'fixes' of git://git.linaro.org/people/rmk/linux-arm:
  ARM: 7529/1: delay: set loops_per_jiffy when moving to timer-based loop
  ARM: 7528/1: uaccess: annotate [__]{get,put}_user functions with might_fault()
  ARM: 7527/1: uaccess: explicitly check __user pointer when !CPU_USE_DOMAINS
  ARM: 7526/1: traps: send SIGILL if get_user fails on undef handling path
  ARM: 7521/1: Fix semihosting Kconfig text
  ARM: 7513/1: Make sure dtc is built before running it
  ARM: 7512/1: Fix XIP build due to PHYS_OFFSET definition moving
  ARM: 7499/1: mm: Fix vmalloc overlap check for !HIGHMEM
  ARM: 7503/1: mm: only flush both pmd entries for classic MMU
  ARM: 7502/1: contextidr: avoid using bfi instruction during notifier
  ARM: 7501/1: decompressor: reset ttbcr for VMSA ARMv7 cores
  ARM: 7497/1: hw_breakpoint: allow single-byte watchpoints on all addresses
  ARM: 7496/1: hw_breakpoint: don't rely on dfsr to show watchpoint access type
  ARM: Fix ioremap() of address zero

The user access functions may generate a fault, resulting in invocation
of a handler that may sleep.

This patch annotates the accessors with might_fault() so that we print a
warning if they are invoked from atomic context and help lockdep keep
track of mmap_sem.

Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

The {get,put}_user macros don't perform range checking on the provided
__user address when !CPU_HAS_DOMAINS.

This patch reworks the out-of-line assembly accessors to check the user
address against a specified limit, returning -EFAULT if is is out of
range.

[will: changed get_user register allocation to match put_user]
[rmk: fixed building on older ARM architectures]

Reported-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Cc: stable@vger.kernel.org
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

During the p2v changes, the PHYS_OFFSET #define moved into a
!__ASSEMBLY__ section. This causes a XIP build to fail with

 arch/arm/kernel/head.o: In function 'stext':
 arch/arm/kernel/head.S:146: undefined reference to 'PHYS_OFFSET'

Momentarily leave the #ifndef __ASSEMBLY__ section so we can
define PHYS_OFFSET for all compilation units.

Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

Some platforms might require to increase atomic coherent pool to make
sure that their device will be able to allocate all their buffers from
atomic context. This function can be also used to decrease atomic
coherent pool size if coherent allocations are not used for the given
sub-platform.

Suggested-by: Josh Coombs <josh.coombs@gmail.com>
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>

LPAE does not use two pmd entries for a pte, so the additional tlb
flushing is not required.

Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

Page migration encodes the pfn in the offset field of a swp_entry_t.
For LPAE, we support physical addresses of up to 36 bits (due to
sparsemem limitations with the size of page flags), requiring 24 bits
to represent a pfn. A further 3 bits are used to encode a swp_entry into
a pte, leaving 5 bits for the type field. Furthermore, the core code
defines MAX_SWAPFILES_SHIFT as 5, so the additional type bit does not
get used.

This patch reduces the width of the type field to 5 bits, allowing us
to create up to 31 swapfiles of 64GB each.

Cc: <stable@vger.kernel.org>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>