linux/arch/arc, branch v4.4

ARC: dw2 unwind: Catch Dwarf SNAFUs early

2015-12-21T08:31:49Z

Instead of seeing empty stack traces, let kernel fail early so dwarf issues can be fixed sooner Signed-off-by: Vineet Gupta

ARC: dw2 unwind: Don't bail for CIE.version != 1

2015-12-21T08:31:25Z

The rudimentary CIE.version == 3 handling is already present in code (for return address register specification) Signed-off-by: Vineet Gupta

Revert "ARC: dw2 unwind: Ignore CIE version !=1 gracefully instead of bailing"

2015-12-21T07:59:44Z

Blingly ignoring CIE.version != 1 was a bad idea. It still leaves "desirability" when running perf with callgraphing where libgcc symbols might show in hotspot. More importantly, basic CIE.version == 3 support already exists in code: | | retAddrReg = state.version <= 1 ? *ptr++ : get_uleb128(&ptr, end); | Next commit with simply add continue-not-bail for CIE.version != 1 This reverts commit 323f41f9e7d0cb5b1d1586aded6682855f1e646d.

ARC: Fix linking errors with CONFIG_MODULE + CONFIG_CC_OPTIMIZE_FOR_SIZE

2015-12-21T07:31:19Z

At -Os, ARC gcc generates millicode thunk for function prologue/epilogue, which are served by libgcc. Modules historically are NOT linked with libgcc to avoid code bloat, reducing runtime relocation fixups etc. I even once tried doing that but got lost in makefile intricacies. This means modules at -Os don't get the millicode thunks, causing build failures below: | MODPOST 5 modules | ERROR: "__ld_r13_to_r18" [crypto/sha256_generic.ko] undefined! | ERROR: "__ld_r13_to_r18_ret" [crypto/sha256_generic.ko] undefined! | ERROR: "__st_r13_to_r18" [crypto/sha256_generic.ko] undefined! | ERROR: "__ld_r13_to_r17_ret" [crypto/sha256_generic.ko] undefined! | ERROR: "__st_r13_to_r17" [crypto/sha256_generic.ko] undefined! | ERROR: "__ld_r13_to_r16_ret" [crypto/sha256_generic.ko] undefined! | ERROR: "__st_r13_to_r16" [crypto/sha256_generic.ko] undefined! |.... |.... Workaround that by inhibiting millicode thunks for loadable modules Fixes STAR 9000641864: ("Linux built with optimizations for size emits errors for modules") Reported-by: Anton Kolesov Cc: Michal Marek Cc: linux-kernel@vger.kernel.org Signed-off-by: Vineet Gupta

ARC: mm: fix building for MMU v2

2015-12-21T06:40:40Z

ARC700 cores with MMU v2 don't have IC_PTAG AUX register and so we only define ARC_REG_IC_PTAG for MMU versions >= 3. But current implementation of cache_line_loop_vX() routines assumes availability of all of them (v2, v3 and v4) simultaneously. And given undefined ARC_REG_IC_PTAG if CONFIG_MMU_VER=2 we're seeing compilation problem: ---------------------------------->8------------------------------- CC arch/arc/mm/cache.o arch/arc/mm/cache.c: In function '__cache_line_loop_v3': arch/arc/mm/cache.c:270:13: error: 'ARC_REG_IC_PTAG' undeclared (first use in this function) aux_tag = ARC_REG_IC_PTAG; ^ arch/arc/mm/cache.c:270:13: note: each undeclared identifier is reported only once for each function it appears in scripts/Makefile.build:258: recipe for target 'arch/arc/mm/cache.o' failed ---------------------------------->8------------------------------- The simples fix is to have ARC_REG_IC_PTAG defined regardless MMU version being used. We don't use it in cache_line_loop_v2() anyways so who cares. Signed-off-by: Alexey Brodkin Signed-off-by: Vineet Gupta

ARC: mm: HIGHMEM: Fix section mismatch splat

2015-12-21T06:40:40Z

| WARNING: vmlinux.o(.text+0xd6c2): Section mismatch in reference from the function alloc_kmap_pgtable() to the function | .init.text:__alloc_bootmem_low() The function alloc_kmap_pgtable() references the function __init __alloc_bootmem_low(). This is often because alloc_kmap_pgtable lacks a __init annotation or the annotation of __alloc_bootmem_low is wrong. Signed-off-by: Vineet Gupta

ARC: smp: Rename platform hook @init_cpu_smp -> @init_per_cpu

2015-12-17T07:26:56Z

Makes it similar to smp_ops which also has callback with same name Signed-off-by: Vineet Gupta

ARC: rename smp operation init_irq_cpu() to init_per_cpu()

2015-12-17T07:26:43Z

This will better reflect its description i.e. "any needed setup..." and not just do an "IPI request". Signed-off-by: Noam Camus Acked-by: Vineet Gupta Signed-off-by: Vineet Gupta

ARC: dw2 unwind: Ignore CIE version !=1 gracefully instead of bailing

2015-12-17T05:40:23Z

ARC dwarf unwinder only supports CIE version == 1 The boot time dwarf sanitizer (part of binary lookup table constructor) would simply bail if it saw CIE version == 3, rendering unwinder with a NULL lookup table. It seems libgcc linked with kernel does have such entries. With fallback linear search removed, and a NULL binary lookup table, unwinder fails to generate any stack trace. So allow graceful ignoring of unsupported CIE entries. This problem was initially seen in Alexey's setup (and not mine) as he was using buildroot built toolchain (libgcc) which doesn't get built with CFLAGS_FOR_TARGET="-gdwarf-2 which is my default Fixes STAR 9000985048: "kernel unwinder broken with stock tools" Fixes: 2e22502c080f ARC: dw2 unwind: Remove falllback linear search thru FDE entries Reported-by Alexey Brodkin Cc: Signed-off-by: Vineet Gupta

ARC: dw2 unwind: Reinstante unwinding out of modules

2015-12-17T05:40:23Z

The fix which removed linear searching of dwarf (because binary lookup data always exists) missed out on the fact that modules don't get the binary lookup tables info. This caused unwinding out of modules to stop working. So add binary lookup header setup (equivalent of eh_frame_hdr setup) to modules as well. While at it, confine the header setup to within unwinder code, reducing one API exposed out of unwinder code. Fixes: 2e22502c080f ARC: dw2 unwind: Remove falllback linear search thru FDE entries Cc: Signed-off-by: Vineet Gupta