[PATCH v2 00/26] genirq: fix use of irq_find_mapping outside of legal RCU context

Marc Zyngier marc.zyngier at arm.com
Wed Aug 27 02:33:44 PDT 2014

Hi Thomas,

On Tue, Aug 26 2014 at 10:34:51 pm BST, Thomas Gleixner <tglx at linutronix.de> wrote:
> On Tue, 26 Aug 2014, Marc Zyngier wrote:
>> A number of irqchip drivers are directly calling irq_find_mapping,
>> which may use a rcu_read_lock call when walking the radix tree.
>> Turns out that if you hit that point with CONFIG_PROVE_RCU enabled,
>> the kernel will shout at you, as using RCU in this context may be
>> illegal (specially if coming from the idle state, where RCU would be
>> in a quiescent state).
>> A possible fix would be to wrap calls to irq_find_mapping into a
>> RCU_NONIDLE macro, but that really looks ugly.
>> This patch series introduce another generic IRQ entry point
>> (handle_domain_irq), which has the exact same behaviour as handle_IRQ
>> (as defined on arm, arm64 and openrisc), except that it also takes a
>> irq_domain pointer. This allows the logical IRQ lookup to be done
>> inside the irq_{enter,exit} section, which contains a
>> rcu_irq_{enter,exit}, making it safe.
> Looks good. Should this be routed to the genirq tree?

I'm happy for you to take this series, provided the architecture
maintainers agree on it (I'm still to hear from the openrisc guys, and
their mailing-list seems to positively hate my guts).


Jazz is not dead. It just smells funny.

More information about the linux-arm-kernel mailing list