kernel/linux.git/arch, branch v3.18.15

ARM: OMAP3: Fix booting with thumb2 kernel

2015-06-12T00:51:53+00:00

We get a NULL pointer dereference on omap3 for thumb2 compiled kernels: Internal error: Oops: 80000005 [#1] SMP THUMB2 ... [] (_raw_spin_unlock_irqrestore) from [] (omap3_enter_idle_bm+0xc5/0x178) [] (omap3_enter_idle_bm) from [] (cpuidle_enter_state+0x77/0x27c) [] (cpuidle_enter_state) from [] (cpu_startup_entry+0x155/0x23c) [] (cpu_startup_entry) from [] (start_kernel+0x32f/0x338) [] (start_kernel) from [<8000807f>] (0x8000807f) The power management related assembly on omaps needs to interact with ARM mode bootrom code, so we need to keep most of the related assembly in ARM mode. Turns out this error is because of missing ENDPROC for assembly code as suggested by Stephen Boyd . Let's fix the problem by adding ENDPROC in two places to sleep34xx.S. Let's also remove the now duplicate custom code for mode switching. This has been unnecessary since commit 6ebbf2ce437b ("ARM: convert all "mov.* pc, reg" to "bx reg" for ARMv6+"). And let's also remove the comments about local variables, they are now just confusing after the ENDPROC. The reason why ENDPROC makes a difference is it sets .type and then the compiler knows what to do with the thumb bit as explained at: https://wiki.ubuntu.com/ARM/Thumb2PortingHowto Reported-by: Kevin Hilman Tested-by: Kevin Hilman Signed-off-by: Tony Lindgren (cherry picked from commit d8a50941c91a68da202aaa96a3dacd471ea9c693) Cc: # v3.18+ Signed-off-by: Kevin Hilman Signed-off-by: Sasha Levin

ARC: unbork !LLSC build

2015-06-10T17:42:46+00:00

[ Upstream commit daaf40e53b5dbdf75255d58a45ce8ac65ca511a8 ] Fixes: f7d11e93ee97a locking,arch,arc: Fold atomic_ops Cc: # 3.18 Signed-off-by: Vineet Gupta Signed-off-by: Sasha Levin

parisc,metag: Fix crashes due to stack randomization on stack-grows-upwards architectures

2015-06-10T17:42:33+00:00

[ Upstream commit d045c77c1a69703143a36169c224429c48b9eecd ] On architectures where the stack grows upwards (CONFIG_STACK_GROWSUP=y, currently parisc and metag only) stack randomization sometimes leads to crashes when the stack ulimit is set to lower values than STACK_RND_MASK (which is 8 MB by default if not defined in arch-specific headers). The problem is, that when the stack vm_area_struct is set up in fs/exec.c, the additional space needed for the stack randomization (as defined by the value of STACK_RND_MASK) was not taken into account yet and as such, when the stack randomization code added a random offset to the stack start, the stack effectively got smaller than what the user defined via rlimit_max(RLIMIT_STACK) which then sometimes leads to out-of-stack situations and crashes. This patch fixes it by adding the maximum possible amount of memory (based on STACK_RND_MASK) which theoretically could be added by the stack randomization code to the initial stack size. That way, the user-defined stack size is always guaranteed to be at minimum what is defined via rlimit_max(RLIMIT_STACK). This bug is currently not visible on the metag architecture, because on metag STACK_RND_MASK is defined to 0 which effectively disables stack randomization. The changes to fs/exec.c are inside an "#ifdef CONFIG_STACK_GROWSUP" section, so it does not affect other platformws beside those where the stack grows upwards (parisc and metag). Signed-off-by: Helge Deller Cc: linux-parisc@vger.kernel.org Cc: James Hogan Cc: linux-metag@vger.kernel.org Cc: stable@vger.kernel.org # v3.16+ Signed-off-by: Sasha Levin

ARM: fix missing syscall trace exit

2015-06-10T17:42:33+00:00

[ Upstream commit 1b97937246d8b97c0760d16d8992c7937bdf5e6a ] Josh Stone reports: I've discovered a case where both arm and arm64 will miss a ptrace syscall-exit that they should report. If the syscall is entered without TIF_SYSCALL_TRACE set, then it goes on the fast path. It's then possible to have TIF_SYSCALL_TRACE added in the middle of the syscall, but ret_fast_syscall doesn't check this flag again. Fix this by always checking for a syscall trace in the fast exit path. Reported-by: Josh Stone Signed-off-by: Russell King Signed-off-by: Sasha Levin

ARM: dts: imx27: only map 4 Kbyte for fec registers

2015-06-10T17:42:32+00:00

[ Upstream commit a29ef819f3f34f89a1b9b6a939b4c1cdfe1e85ce ] According to the imx27 documentation, fec has a 4 Kbyte memory space map. Moreover, the actual 16 Kbyte mapping overlaps the SCC (Security Controller) memory register space. So, we reduce the memory register space to 4 Kbyte. Signed-off-by: Philippe Reynes Acked-by: Uwe Kleine-König Fixes: 9f0749e3eb88 ("ARM i.MX27: Add devicetree support") Cc: Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin

ARM: 8356/1: mm: handle non-pmd-aligned end of RAM

2015-06-10T17:42:31+00:00

[ Upstream commit 965278dcb8ab0b1f666cc47937933c4be4aea48d ] At boot time we round the memblock limit down to section size in an attempt to ensure that we will have mapped this RAM with section mappings prior to allocating from it. When mapping RAM we iterate over PMD-sized chunks, creating these section mappings. Section mappings are only created when the end of a chunk is aligned to section size. Unfortunately, with classic page tables (where PMD_SIZE is 2 * SECTION_SIZE) this means that if a chunk is between 1M and 2M in size the first 1M will not be mapped despite having been accounted for in the memblock limit. This has been observed to result in page tables being allocated from unmapped memory, causing boot-time hangs. This patch modifies the memblock limit rounding to always round down to PMD_SIZE instead of SECTION_SIZE. For classic MMU this means that we will round the memblock limit down to a 2M boundary, matching the limits on section mappings, and preventing allocations from unmapped memory. For LPAE there should be no change as PMD_SIZE == SECTION_SIZE. Signed-off-by: Mark Rutland Reported-by: Stefan Agner Tested-by: Stefan Agner Acked-by: Laura Abbott Tested-by: Hans de Goede Cc: Catalin Marinas Cc: Steve Capper Cc: stable@vger.kernel.org Signed-off-by: Russell King Signed-off-by: Sasha Levin

s390/mm: correct return value of pmd_pfn

2015-06-10T17:42:30+00:00

[ Upstream commit 7cded342c09f633666e71ee1ce048f218a9c5836 ] Git commit 152125b7a882df36a55a8eadbea6d0edf1461ee7 "s390/mm: implement dirty bits for large segment table entries" broke the pmd_pfn function, it changed the return value from 'unsigned long' to 'int'. This breaks all machine configurations with memory above the 8TB line. Cc: stable@vger.kernel.org # 3.17+ Signed-off-by: Martin Schwidefsky Signed-off-by: Sasha Levin

crypto: s390/ghash - Fix incorrect ghash icv buffer handling.

2015-06-10T17:42:28+00:00

[ Upstream commit a1cae34e23b1293eccbcc8ee9b39298039c3952a ] Multitheaded tests showed that the icv buffer in the current ghash implementation is not handled correctly. A move of this working ghash buffer value to the descriptor context fixed this. Code is tested and verified with an multithreaded application via af_alg interface. Cc: stable@vger.kernel.org Signed-off-by: Harald Freudenberger Signed-off-by: Gerald Schaefer Reported-by: Herbert Xu Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin

arm64: bpf: fix signedness bug in loading 64-bit immediate

2015-06-10T17:42:27+00:00

[ Upstream commit 1e4df6b7208140f3c49f316d33a409d3a161f350 ] Consider "(u64)insn1.imm << 32 | imm" in the arm64 JIT. Since imm is signed 32-bit, it is sign-extended to 64-bit, losing the high 32 bits. The fix is to convert imm to u32 first, which will be zero-extended to u64 implicitly. Cc: Zi Shen Lim Cc: Alexei Starovoitov Cc: Catalin Marinas Cc: Fixes: 30d3d94cc3d5 ("arm64: bpf: add 'load 64-bit immediate' instruction") Signed-off-by: Xi Wang [will: removed non-arm64 bits and redundant casting] Signed-off-by: Will Deacon Signed-off-by: Sasha Levin

powerpc: Align TOC to 256 bytes

2015-06-10T17:42:21+00:00

[ Upstream commit 5e95235ccd5442d4a4fe11ec4eb99ba1b7959368 ] Recent toolchains force the TOC to be 256 byte aligned. We need to enforce this alignment in our linker script, otherwise pointers to our TOC variables (__toc_start, __prom_init_toc_start) could be incorrect. If they are bad, we die a few hundred instructions into boot. Cc: stable@vger.kernel.org Signed-off-by: Anton Blanchard Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin