kernel.git/arch/parisc/kernel/irq.c, branch linux-3.12.y

parisc: Filter out spurious interrupts in PA-RISC irq handler

2015-09-30T09:13:08Z

commit b1b4e435e4ef7de77f07bf2a42c8380b960c2d44 upstream. When detecting a serial port on newer PA-RISC machines (with iosapic) we have a long way to go to find the right IRQ line, registering it, then registering the serial port and the irq handler for the serial port. During this phase spurious interrupts for the serial port may happen which then crashes the kernel because the action handler might not have been set up yet. So, basically it's a race condition between the serial port hardware and the CPU which sets up the necessary fields in the irq sructs. The main reason for this race is, that we unmask the serial port irqs too early without having set up everything properly before (which isn't easily possible because we need the IRQ number to register the serial ports). This patch is a work-around for this problem. It adds checks to the CPU irq handler to verify if the IRQ action field has been initialized already. If not, we just skip this interrupt (which isn't critical for a serial port at bootup). The real fix would probably involve rewriting all PA-RISC specific IRQ code (for CPU, IOSAPIC, GSC and EISA) to use IRQ domains with proper parenting of the irq chips and proper irq enabling along this line. This bug has been in the PA-RISC port since the beginning, but the crashes happened very rarely with currently used hardware. But on the latest machine which I bought (a C8000 workstation), which uses the fastest CPUs (4 x PA8900, 1GHz) and which has the largest possible L1 cache size (64MB each), the kernel crashed at every boot because of this race. So, without this patch the machine would currently be unuseable. For the record, here is the flow logic: 1. serial_init_chip() in 8250_gsc.c calls iosapic_serial_irq(). 2. iosapic_serial_irq() calls txn_alloc_irq() to find the irq. 3. iosapic_serial_irq() calls cpu_claim_irq() to register the CPU irq 4. cpu_claim_irq() unmasks the CPU irq (which it shouldn't!) 5. serial_init_chip() then registers the 8250 port. Problems: - In step 4 the CPU irq shouldn't have been registered yet, but after step 5 - If serial irq happens between 4 and 5 have finished, the kernel will crash Signed-off-by: Helge Deller Signed-off-by: Jiri Slaby

parisc: fix irq stack on UP and SMP

2013-05-24T21:29:01Z

The logic to detect if the irq stack was already in use with raw_spin_trylock() is wrong, because it will generate a "trylock failure on UP" error message with CONFIG_SMP=n and CONFIG_DEBUG_SPINLOCK=y. arch_spin_trylock() can't be used either since in the CONFIG_SMP=n case no atomic protection is given and we are reentrant here. A mutex didn't worked either and brings more overhead by turning off interrupts. So, let's use the fastest path for parisc which is the ldcw instruction. Counting how often the irq stack was used is pretty useless, so just drop this piece of code. Signed-off-by: Helge Deller

parisc: show number of FPE and unaligned access handler calls in /proc/interrupts

2013-05-24T20:35:26Z

Show number of floating point assistant and unaligned access fixup handler in /proc/interrupts file. Signed-off-by: Helge Deller

parisc: implement irq stacks - part 2 (v2)

2013-05-11T19:10:15Z

This patch fixes few build issues which were introduced with the last irq stack patch, e.g. the combination of stack overflow check and irq stack. Furthermore we now do proper locking and change the irq bh handler to use the irq stack as well. In /proc/interrupts one now can monitor how huge the irq stack has grown and how often it was preferred over the kernel stack. IRQ stacks are now enabled by default just to make sure that we not overflow the kernel stack by accident. Signed-off-by: Helge Deller

parisc: tlb flush counting fix for SMP and UP

2013-05-07T21:44:04Z

Fix up build error on UP and show correctly number of function call (ipi) irqs. Signed-off-by: Helge Deller

parisc: more irq statistics in /proc/interrupts

2013-05-07T20:39:22Z

Add framework and initial values for more fine grained statistics in /proc/interrupts. Signed-off-by: Helge Deller

parisc: implement irq stacks

2013-05-07T20:30:35Z

Default kernel stack size on parisc is 16k. During tests we found that the kernel stack can easily grow beyond 13k, which leaves 3k left for irq processing. This patch adds the possibility to activate an additional stack of 16k per CPU which is being used during irq processing. This implementation does not yet uses this irq stack for the irq bh handler. The assembler code for call_on_stack was heavily cleaned up by John David Anglin. CC: John David Anglin Signed-off-by: Helge Deller

parisc: add kernel stack overflow check

2013-05-07T19:34:07Z

Add the CONFIG_DEBUG_STACKOVERFLOW config option to enable checks to detect kernel stack overflows. Stack overflows can not be detected reliable since we do not want to introduce too much overhead. Instead, during irq processing in do_cpu_irq_mask() we check kernel stack usage of the interrupted kernel process. Kernel threads can be easily detected by checking the value of space register 7 (sr7) which is zero when running inside the kernel. Since THREAD_SIZE is 16k and PAGE_SIZE is 4k, reduce the alignment of the init thread to the lower value (PAGE_SIZE) in the kernel vmlinux.ld.S linker script. Signed-off-by: Helge Deller

parisc: remove IRQF_DISABLED

2013-02-20T21:50:26Z

People are playing odd games with IRQF_DISABLED, remove it. Its not reliable, since shared interrupt lines could disable it for you, and its possible and allowed for archs to disable IRQs to limit IRQ nesting. Therefore, simply mandate that _ALL_ IRQ handlers are run with IRQs disabled. [ This _should_ not break anything, since we've mandated that IRQ handlers _must_ be able to deal with this for a _long_ time ] IRQ handlers should be fast, no if buts and any other exceptions. We also have plenty instrumentation to find any offending IRQ latency sources. Signed-off-by: Peter Zijlstra Acked-by: Ingo Molnar Signed-off-by: Helge Deller

parisc: don't claim cpu irqs more than once

2013-01-07T22:06:23Z

The CPU irqs (timer and IPI) are not shared and only need to be claimed once. A mismatch error occurs if they are claimed more than once. Signed-off-by: John David Anglin Cc: Kyle McMartin Cc: Helge Deller Cc: "James E.J. Bottomley" Signed-off-by: Helge Deller