user/sven/linux.git/arch/arc/include, branch v4.4.27

ARC: uaccess: get_user to zero out dest in cause of fault

2016-09-24T08:07:44Z

commit 05d9d0b96e53c52a113fd783c0c97c830c8dc7af upstream. Al reported potential issue with ARC get_user() as it wasn't clearing out destination pointer in case of fault due to bad address etc. Verified using following | { | u32 bogus1 = 0xdeadbeef; | u64 bogus2 = 0xdead; | int rc1, rc2; | | pr_info("Orig values %x %llx\n", bogus1, bogus2); | rc1 = get_user(bogus1, (u32 __user *)0x40000000); | rc2 = get_user(bogus2, (u64 __user *)0x50000000); | pr_info("access %d %d, new values %x %llx\n", | rc1, rc2, bogus1, bogus2); | } | [ARCLinux]# insmod /mnt/kernel-module/qtn.ko | Orig values deadbeef dead | access -14 -14, new values 0 0 Reported-by: Al Viro Cc: Linus Torvalds Cc: linux-snps-arc@lists.infradead.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Vineet Gupta Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman

ARC: mm: fix build breakage with STRICT_MM_TYPECHECKS

2016-09-24T08:07:37Z

commit 1c3c909303924d30145601f47b6c058fdd2cbc2e upstream. | CC mm/memory.o | In file included from ../mm/memory.c:53:0: | ../include/linux/pfn_t.h: In function ‘pfn_t_pte’: | ../include/linux/pfn_t.h:78:2: error: conversion to non-scalar type requested | return pfn_pte(pfn_t_to_pfn(pfn), pgprot); With STRICT_MM_TYPECHECKS pte_t is a struct and the offending code forces a cast which ends up shifting a struct and hence the gcc warning. Note that in recent past some of the arches (aarch64, s390) made STRICT_MM_TYPECHECKS default, but we don't for ARC as this leads to slightly worse generated code, given ARC ABI definition of returning structs (which pte_t would become) Quoting from ARC ABI... "Results of type struct are returned in a caller-supplied temporary variable whose address is passed in r0. For such functions, the arguments are shifted so that they are passed in r1 and up." So - struct to be returned would be allocated on stack requiring extra code at call sites - callee updates stack memory to facilitate the return (vs. simple MOV into return reg r0) Hence STRICT_MM_TYPECHECKS is not enabled by default for ARC Signed-off-by: Vineet Gupta Signed-off-by: Greg Kroah-Hartman

ARC: Call trace_hardirqs_on() before enabling irqs

2016-09-07T06:32:42Z

commit 18b43e89d295cc65151c505c643c98fb2c320e59 upstream. trace_hardirqs_on_caller() in lockdep.c expects to be called before, not after interrupts are actually enabled. The following comment in kernel/locking/lockdep.c substantiates this claim: " /* * We're enabling irqs and according to our state above irqs weren't * already enabled, yet we find the hardware thinks they are in fact * enabled.. someone messed up their IRQ state tracing. */ " An example can be found in include/linux/irqflags.h: do { trace_hardirqs_on(); raw_local_irq_enable(); } while (0) Without this change, we hit the following DEBUG_LOCKS_WARN_ON. [ 7.760000] ------------[ cut here ]------------ [ 7.760000] WARNING: CPU: 0 PID: 1 at kernel/locking/lockdep.c:2711 resume_user_mode_begin+0x48/0xf0 [ 7.770000] DEBUG_LOCKS_WARN_ON(!irqs_disabled()) [ 7.780000] Modules linked in: [ 7.780000] CPU: 0 PID: 1 Comm: init Not tainted 4.7.0-00003-gc668bb9-dirty #366 [ 7.790000] [ 7.790000] Stack Trace: [ 7.790000] arc_unwind_core.constprop.1+0xa4/0x118 [ 7.800000] warn_slowpath_fmt+0x72/0x158 [ 7.800000] resume_user_mode_begin+0x48/0xf0 [ 7.810000] ---[ end trace 6f6a7a8fae20d2f0 ]--- Signed-off-by: Daniel Mentz Signed-off-by: Vineet Gupta Signed-off-by: Greg Kroah-Hartman

ARC: use correct offset in pt_regs for saving/restoring user mode r25

2016-09-07T06:32:42Z

commit 86147e3cfa5e118b61e78f4f0bf29e920dcbd477 upstream. User mode callee regs are explicitly collected before signal delivery or breakpoint trap. r25 is special for kernel as it serves as task pointer, so user mode value is clobbered very early. It is saved in pt_regs where generally only scratch (aka caller saved) regs are saved. The code to access the corresponding pt_regs location had a subtle bug as it was using load/store with scaling of offset, whereas the offset was already byte wise correct. So fix this by replacing LD.AS with a standard LD Signed-off-by: Liav Rehana Reviewed-by: Alexey Brodkin [vgupta: rewrote title and commit log] Signed-off-by: Vineet Gupta Signed-off-by: Greg Kroah-Hartman

ARC: build: Better way to detect ISA compatible toolchain

2016-09-07T06:32:42Z

commit 20d780374c81cf237834af2202c26df2100ddd69 upstream. ARC architecture has 2 instruction sets: ARCompact/ARCv2. While same gcc supports compiling for either (using appropriate toggles), we can't use the same toolchain to build kernel because libgcc needs to be unique and the toolchian (uClibc based) is not multilibed. uClibc toolchain is convenient since it allows all userspace and kernel to be built with a single install for an ISA. This however means 2 gnu installs (with same triplet prefix) are needed for building for 2 ISA and need to be in PATH. As developers we keep switching the builds, but would occassionally fail to update the PATH leading to usage of wrong tools. And this would only show up at the end of kernel build when linking incompatible libgcc. So the initial solution was to have gcc define a special preprocessor macro DEFAULT_CPU_xxx which is unique for default toolchain configuration. Claudiu proposed using grep for an existing preprocessor macro which is again uniquely defined per ISA. Cc: Michal Marek Suggested-by: Claudiu Zissulescu Signed-off-by: Vineet Gupta Signed-off-by: Greg Kroah-Hartman

ARC: mm: don't loose PTE_SPECIAL in pte_modify()

2016-08-20T16:09:20Z

commit 3925a16ae980c79d1a8fd182d7f9487da1edd4dc upstream. LTP madvise05 was generating mm splat | [ARCLinux]# /sd/ltp/testcases/bin/madvise05 | BUG: Bad page map in process madvise05 pte:80e08211 pmd:9f7d4000 | page:9fdcfc90 count:1 mapcount:-1 mapping: (null) index:0x0 flags: 0x404(referenced|reserved) | page dumped because: bad pte | addr:200b8000 vm_flags:00000070 anon_vma: (null) mapping: (null) index:1005c | file: (null) fault: (null) mmap: (null) readpage: (null) | CPU: 2 PID: 6707 Comm: madvise05 And for newer kernels, the system was rendered unusable afterwards. The problem was mprotect->pte_modify() clearing PTE_SPECIAL (which is set to identify the special zero page wired to the pte). When pte was finally unmapped, special casing for zero page was not done, and instead it was treated as a "normal" page, tripping on the map counts etc. This fixes ARC STAR 9001053308 Signed-off-by: Vineet Gupta Signed-off-by: Greg Kroah-Hartman

ARC: Add missing io barriers to io{read,write}{16,32}be()

2016-05-11T09:21:20Z

commit e5bc0478ab6cf565619224536d75ecb2aedca43b upstream. While reviewing a different change to asm-generic/io.h Arnd spotted that ARC ioread32 and ioread32be both of which come from asm-generic versions are not symmetrical in terms of calling the io barriers. generic ioread32 -> ARC readl() [ has barriers] generic ioread32be -> __be32_to_cpu(__raw_readl()) [ lacks barriers] While generic ioread32be is being remediated to call readl(), that involves a swab32(), causing double swaps on ioread32be() on Big Endian systems. So provide our versions of big endian IO accessors to ensure io barrier calls while also keeping them optimal Suggested-by: Arnd Bergmann Acked-by: Arnd Bergmann Signed-off-by: Vineet Gupta Signed-off-by: Greg Kroah-Hartman

ARC: bitops: Remove non relevant comments

2016-04-12T16:08:56Z

commit 2a41b6dc28dc71c1a3f1622612a26edc58f7561e upstream. commit 80f420842ff42 removed the ARC bitops microoptimization but failed to prune the comments to same effect Fixes: 80f420842ff42 ("ARC: Make ARC bitops "safer" (add anti-optimization)") Signed-off-by: Vineet Gupta Signed-off-by: Greg Kroah-Hartman

ARC: [BE] readl()/writel() to work in Big Endian CPU configuration

2016-04-12T16:08:56Z

commit f778cc65717687a3d3f26dd21bef62cd059f1b8b upstream. read{l,w}() write{l,w}() primitives should use le{16,32}_to_cpu() and cpu_to_le{16,32}() respectively to ensure device registers are read correctly in Big Endian CPU configuration. Per Arnd Bergmann | Most drivers using readl() or readl_relaxed() expect those to perform byte | swaps on big-endian architectures, as the registers tend to be fixed endian This was needed for getting UART to work correctly on a Big Endian ARC. The ARC accessors originally were fine, and the bug got introduced inadventently by commit b8a033023994 ("ARCv2: barriers") Fixes: b8a033023994 ("ARCv2: barriers") Link: http://lkml.kernel.org/r/201603100845.30602.arnd@arndb.de Cc: Alexey Brodkin Cc: Arnd Bergmann Signed-off-by: Lada Trimasova [vgupta: beefed up changelog, added Fixes/stable tags] Signed-off-by: Vineet Gupta Signed-off-by: Greg Kroah-Hartman

ARCv2: SMP: Emulate IPI to self using software triggered interrupt

2016-03-03T23:07:28Z

commit bb143f814ea488769ca2e79e0b376139cb5f134b upstream. ARConnect/MCIP Inter-Core-Interrupt module can't send interrupt to local core. So use core intc capability to trigger software interrupt to self, using an unsued IRQ #21. This showed up as csd deadlock with LTP trace_sched on a dual core system. This test acts as scheduler fuzzer, triggering all sorts of schedulting activity. Trouble starts with IPI to self, which doesn't get delivered (effectively lost due to H/w capability), but the msg intended to be sent remain enqueued in per-cpu @ipi_data. All subsequent IPIs to this core from other cores get elided due to the IPI coalescing optimization in ipi_send_msg_one() where a pending msg implies an IPI already sent and assumes other core is yet to ack it. After the elided IPI, other core simply goes into csd_lock_wait() but never comes out as this core never sees the interrupt. Fixes STAR 9001008624 Cc: Peter Zijlstra Signed-off-by: Vineet Gupta Signed-off-by: Greg Kroah-Hartman