lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 14 Jul 2015 11:02:40 +0200 From: Ralf Baechle <ralf@...ux-mips.org> To: Manuel Lauss <manuel.lauss@...il.com> Cc: Thomas Gleixner <tglx@...utronix.de>, LKML <linux-kernel@...r.kernel.org>, Jiang Liu <jiang.liu@...ux.intel.com>, Linux-MIPS <linux-mips@...ux-mips.org> Subject: Re: [patch 08/12] MIPS/alchemy: Remove pointless irqdisable/enable On Tue, Jul 14, 2015 at 10:55:08AM +0200, Manuel Lauss wrote: > On Tue, Jul 14, 2015 at 10:16 AM, Thomas Gleixner <tglx@...utronix.de> wrote: > > On Tue, 14 Jul 2015, Manuel Lauss wrote: > > > >> On Mon, Jul 13, 2015 at 10:46 PM, Thomas Gleixner <tglx@...utronix.de> wrote: > >> > bcsr_csc_handler() is a cascading interrupt handler. It has a > >> > disable_irq_nosync()/enable_irq() pair around the generic_handle_irq() > >> > call. The value of this disable/enable is zero because its a complete > >> > noop: > >> > > >> > disable_irq_nosync() merily increments the disable count without > >> > actually masking the interrupt. enable_irq() soleley decrements the > >> > disable count without touching the interrupt chip. The interrupt > >> > cannot arrive again because the complete call chain runs with > >> > interrupts disabled. > >> > > >> > Remove it. > >> > >> Is there another patch this one depends on? The DB1300 board doesn't > > > > No. > > > >> boot (i.e. interrupts from the cpld aren't serviced) with this patch applied: > >> (irq 136 is the first serviced by the bcsr cpld): > >> > >> irq 136: nobody cared (try booting with the "irqpoll" option) > > > > That's weird. Looking deeper, enable_irq() actually calls > > chip->unmask() unconditionally. So it seems the chip is sensitive to > > that. > > > > Does the following patch on top fix things again? > > > > Thanks, > > > > tglx > > ---- > > diff --git a/arch/mips/alchemy/devboards/bcsr.c b/arch/mips/alchemy/devboards/bcsr.c > > index 3a24f2d6ecfd..ec47abe580c6 100644 > > --- a/arch/mips/alchemy/devboards/bcsr.c > > +++ b/arch/mips/alchemy/devboards/bcsr.c > > @@ -88,8 +88,11 @@ EXPORT_SYMBOL_GPL(bcsr_mod); > > static void bcsr_csc_handler(unsigned int irq, struct irq_desc *d) > > { > > unsigned short bisr = __raw_readw(bcsr_virt + BCSR_REG_INTSTAT); > > + struct irq_chip *chip = irq_desc_get_chip(d); > > > > + chained_irq_enter(chip, d); > > generic_handle_irq(bcsr_csc_base + __ffs(bisr)); > > + chained_irq_exit(chip, d); > > } > > > > static void bcsr_irq_mask(struct irq_data *d) > > > Yes. Add #include <linux/irqchip/chained_irq.h> on top and it works again. > This hardware is problematic, an older variant with identical verilog > code in the cpld's > irq unit works fine without this. So shall I merge both patches and the header file change together or? Ralf -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists