linux/arch/arc/kernel, 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: 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

ARC: intc: Document arc_request_percpu_irq() better

2015-12-12T10:34:12Z

Signed-off-by: Vineet Gupta

ARCv2: perf: Ensure perf intr gets enabled on all cores

2015-12-12T10:33:59Z

This was the second perf intr issue perf sampling on multicore requires intr to be enabled on all cores. ARC perf probe code used helper arc_request_percpu_irq() which calls - request_percpu_irq() on core0 - enable_percpu_irq() on all all cores (including core0) genirq requires that request be made ahead of enable call. However if perf probe happened on non core0 (observed on a 3.18 kernel), enable would get called ahead of request, failing obviously and rendering perf intr disabled on all such cores [ 11.120000] 1 ARC perf : 8 counters (48 bits), 113 conditions, [overflow IRQ support] [ 11.130000] 1 -----> enable_percpu_irq() IRQ 20 failed [ 11.140000] 3 -----> enable_percpu_irq() IRQ 20 failed [ 11.140000] 2 -----> enable_percpu_irq() IRQ 20 failed [ 11.140000] 0 =====> request_percpu_irq() IRQ 20 [ 11.140000] 0 -----> enable_percpu_irq() IRQ 20 Fix this fragility, by calling request_percpu_irq() on whatever core calls probe (there is no requirement on which core calls this anyways) and then calling enable on each cores. Interestingly this started as invesigation of STAR 9000838902: "sporadically IRQs enabled on perf prob" which was about occassional boot spew as request_percpu_irq got called non-locally (from an IPI), and re-enabled interrupts in following path proc_mkdir -> spin_unlock_irq() which the irq work code didn't like. | ARC perf : 8 counters (48 bits), 113 conditions, [overflow IRQ support] | | BUG: failure at ../kernel/irq_work.c:135/irq_work_run_list()! | CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.18.10-01127-g285efb8e66d1 #2 | | Stack Trace: | arc_unwind_core.constprop.1+0x94/0x104 | dump_stack+0x62/0x98 | irq_work_run_list+0xb0/0xb4 | irq_work_run+0x22/0x3c | do_IPI+0x74/0x9c | handle_irq_event_percpu+0x34/0x164 | handle_percpu_irq+0x58/0x78 | generic_handle_irq+0x1e/0x2c | arch_do_IRQ+0x3c/0x60 | ret_from_exception+0x0/0x8 Cc: Marc Zyngier Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: linux-snps-arc@lists.infradead.org Cc: linux-kernel@vger.kernel.org Cc: Alexey Brodkin Cc: #4.2+ Signed-off-by: Vineet Gupta

ARC: intc: No need to clear IRQ_NOAUTOEN

2015-12-12T10:33:59Z

arc_request_percpu_irq() is called by all cores to request/enable percpu irq. It has some "prep" calls needed by genirq: - setup percpu devid - disable IRQ_NOAUTOEN However given that enable_percpu_irq() is called enayways, latter can be avoided. We are now left with irq_set_percpu_devid() quirk and that too for ARCompact builds only, since previous patch updated ARCv2 intc to do this in the "right" place, i.e. irq map function. By next release, this will ultimately be fixed for ARCompact as well. Cc: Marc Zyngier Cc: Thomas Gleixner Cc: Alexey Brodkin Cc: linux-snps-arc@lists.infradead.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Vineet Gupta