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: Wed, 30 May 2012 11:55:56 +0900 From: Paul Mundt <lethal@...ux-sh.org> To: Sundar Iyer <sundar.iyer@...el.com> Cc: tglx@...utronix.de, linux-kernel@...r.kernel.org, arjan.van.de.ven@...el.com, german.monroy@...el.com Subject: Re: [PATCH v1] x86/irq: handle chained interrupts during IRQ migration On Tue, May 29, 2012 at 07:10:08PM +0530, Sundar Iyer wrote: > diff --git a/include/linux/irqdesc.h b/include/linux/irqdesc.h > index 2d921b3..7880722 100644 > --- a/include/linux/irqdesc.h > +++ b/include/linux/irqdesc.h > @@ -120,6 +120,16 @@ static inline int irq_has_action(unsigned int irq) > return desc->action != NULL; > } > > +/* > + * Test to see if the IRQ is chained; it would not be requested and hence > + * _IRQ_NOREQUEST would be set > + */ > +static inline int irq_is_chained(unsigned int irq) > +{ > + struct irq_desc *desc = irq_to_desc(irq); > + return !(desc->status_use_accessors & IRQ_NOREQUEST); > +} > + This approach looks highly suspect. There are many non-chained cases that are also NOREQUEST. Chained IRQs are at the very least NOREQUEST, NOPROBE, and NOTHREAD. You could test a mask of those and at least have a vague change of not catching other unrelated IRQs. It would still be a hack though, given that none of those status flags in and of themselves require an IRQ to be chained. -- 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