Re: [PATCH v2 00/26] genirq: fix use of irq_find_mapping outside of legal RCU context
On Tue, Aug 26, 2014 at 11:03:15AM +0100, 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.
>
> A number of irqchips are then converted to this new entry point. I've
> converted all the direct users of irq_find_mapping, except for the
> cases where it was used as a chained handler (chained_irq_{enter,exit}
> makes it safe). Users of irq_linear_revmap are safe as well. I've
> given it some light testing on arm64.
>
> The series is also available in my tree:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git
> handle_domain_irq
>
> From v1 [1]:
> - Made handle_domain_irq a generic function
> - Added OpenRISC to the list of affected architectures
> - Converted more interrupt controllers
> - Rebased on v3.17-rc1
>
> [1]: https://lkml.org/lkml/2014/7/8/381
>
> Marc Zyngier (26):
> genirq: add irq_domain-aware core IRQ handler
> arm64: convert handle_IRQ to use __handle_domain_irq
> ARM: convert handle_IRQ to use __handle_domain_irq
> openrisc: convert handle_IRQ to use __handle_domain_irq
> irqchip: GIC: convert to handle_domain_irq
> irqchip: armada-370-xp: convert to handle_domain_irq
> irqchip: clps711x: convert to handle_domain_irq
> irqchip: mmp: convert to handle_domain_irq
> irqchip: mxs: convert to handle_domain_irq
> irqchip: orion: convert to handle_domain_irq
> irqchip: s3c24xx: convert to handle_domain_irq
> irqchip: sirfsoc: convert to handle_domain_irq
> irqchip: sun4i: convert to handle_domain_irq
> irqchip: versatile-fpga: convert to handle_domain_irq
> irqchip: vic: convert to handle_domain_irq
> irqchip: vt8500: convert to handle_domain_irq
> irqchip: zevio: convert to handle_domain_irq
> irqchip: GICv3: convert to handle_domain_irq
> irqchip: atmel-aic: convert to handle_domain_irq
> irqchip: atmel-aic5: convert to handle_domain_irq
> irqchip: or1k-pic: convert to handle_domain_irq
> ARM: imx: avic: convert to handle_domain_irq
> ARM: imx: tzic: convert to handle_domain_irq
> ARM: omap2: irq: convert to handle_domain_irq
> arm64: get rid of handle_IRQ
> openrisc: get rid of handle_IRQ
>
> arch/arm/Kconfig | 1 +
> arch/arm/kernel/irq.c| 19 +---
> arch/arm/mach-imx/avic.c | 2 +-
> arch/arm/mach-imx/tzic.c | 3 +--
> arch/arm/mach-omap2/irq.c| 3 +--
> arch/arm64/Kconfig | 1 +
> arch/arm64/include/asm/hardirq.h | 2 --
> arch/arm64/kernel/irq.c | 27 ---
> arch/openrisc/Kconfig| 1 +
> arch/openrisc/include/asm/irq.h | 1 -
> arch/openrisc/kernel/irq.c | 12 ---
> drivers/irqchip/irq-armada-370-xp.c | 19
> drivers/irqchip/irq-atmel-aic.c | 4 +---
> drivers/irqchip/irq-atmel-aic5.c | 4 +---
> drivers/irqchip/irq-clps711x.c | 18 ++--
> drivers/irqchip/irq-gic-v3.c | 13 ++-
> drivers/irqchip/irq-gic.c| 3 +--
> drivers/irqchip/irq-mmp.c| 10 -
> drivers/irqchip/irq-mxs.c| 3 +--
> drivers/irqchip/irq-or1k-pic.c | 4 ++--
> drivers/irqchip/irq-orion.c | 5 ++---
> drivers/irqchip/irq-s3c24xx.c| 4 +---
> drivers/irqchip/irq-sirfsoc.c| 6 ++
> drivers/irqchip/irq-sun4i.c | 5 ++---
> drivers/irqchip/irq-versatile-fpga.c | 2 +-
> drivers/irqchip/irq-vic.c| 2 +-
> drivers/irqchip/irq-vt8500.c | 5 ++---
> drivers/irqchip/irq-zevio.c | 3 +--
> include/linux/irqdesc.h | 19
> kernel/irq/Kconfig | 3 +++
> kernel/irq/irqdesc.c | 42
>
> 31 files changed, 116 insertions(+), 130 deletions(-)
Whole series applied to irqchip/handle_domain with Acks applied and
subject line tweaked for capitalization. Turns out we have the openrisc
Ack from:
https://lkml.kernel.org/r/20140827170905.ga5...@chokladfabriken.org
I'll let this sit in -next for a few days and then merge it into
irqchip/core.
thx,
Jason.
--
To unsubscribe from th
Re: [PATCH v2 00/26] genirq: fix use of irq_find_mapping outside of legal RCU context
On 03/09/14 13:37, Jason Cooper wrote:
> On Wed, Sep 03, 2014 at 02:25:09PM +0200, Thomas Gleixner wrote:
>> On Wed, 3 Sep 2014, Marc Zyngier wrote:
>>> [Dropping li...@openrisc.net from the CC list]
>>>
>>> On 03/09/14 13:09, Thomas Gleixner wrote:
On Wed, 3 Sep 2014, Jason Cooper wrote:
> On Wed, Aug 27, 2014 at 10:33:44AM +0100, Marc Zyngier wrote:
>> Hi Thomas,
>>
>> On Tue, Aug 26 2014 at 10:34:51 pm BST, Thomas Gleixner
>> 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).
>
> I think everyone's had a chance to look over it by now. Thomas, shall I
> take the series?
Yes please.
>>>
>>> Do you want a pull request? Or are you picking up the patches from the ML?
>>
>> Did you pick up the Acked/Reviewed/Ignored-by tags?
>
> Marc, unless you've already done it, I'll pull from the ml, since I need
> to apply the Acked-bys and tweak the subject lines.
If you're going to repaint the subject lines, then I'll leave you to it! ;-)
M.
--
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 00/26] genirq: fix use of irq_find_mapping outside of legal RCU context
On 03/09/14 13:25, Thomas Gleixner wrote:
> On Wed, 3 Sep 2014, Marc Zyngier wrote:
>> [Dropping li...@openrisc.net from the CC list]
>>
>> On 03/09/14 13:09, Thomas Gleixner wrote:
>>> On Wed, 3 Sep 2014, Jason Cooper wrote:
>>>
On Wed, Aug 27, 2014 at 10:33:44AM +0100, Marc Zyngier wrote:
> Hi Thomas,
>
> On Tue, Aug 26 2014 at 10:34:51 pm BST, Thomas Gleixner
> 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).
I think everyone's had a chance to look over it by now. Thomas, shall I
take the series?
>>>
>>> Yes please.
>>
>> Do you want a pull request? Or are you picking up the patches from the ML?
>
> Did you pick up the Acked/Reviewed/Ignored-by tags?
I have them in a separate branch that can be pushed out as required.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 00/26] genirq: fix use of irq_find_mapping outside of legal RCU context
On Wed, Sep 03, 2014 at 02:25:09PM +0200, Thomas Gleixner wrote:
> On Wed, 3 Sep 2014, Marc Zyngier wrote:
> > [Dropping li...@openrisc.net from the CC list]
> >
> > On 03/09/14 13:09, Thomas Gleixner wrote:
> > > On Wed, 3 Sep 2014, Jason Cooper wrote:
> > >
> > >> On Wed, Aug 27, 2014 at 10:33:44AM +0100, Marc Zyngier wrote:
> > >>> Hi Thomas,
> > >>>
> > >>> On Tue, Aug 26 2014 at 10:34:51 pm BST, Thomas Gleixner
> > >>> 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).
> > >>
> > >> I think everyone's had a chance to look over it by now. Thomas, shall I
> > >> take the series?
> > >
> > > Yes please.
> >
> > Do you want a pull request? Or are you picking up the patches from the ML?
>
> Did you pick up the Acked/Reviewed/Ignored-by tags?
Marc, unless you've already done it, I'll pull from the ml, since I need
to apply the Acked-bys and tweak the subject lines.
thx,
Jason.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 00/26] genirq: fix use of irq_find_mapping outside of legal RCU context
On Wed, 3 Sep 2014, Marc Zyngier wrote:
> [Dropping li...@openrisc.net from the CC list]
>
> On 03/09/14 13:09, Thomas Gleixner wrote:
> > On Wed, 3 Sep 2014, Jason Cooper wrote:
> >
> >> On Wed, Aug 27, 2014 at 10:33:44AM +0100, Marc Zyngier wrote:
> >>> Hi Thomas,
> >>>
> >>> On Tue, Aug 26 2014 at 10:34:51 pm BST, Thomas Gleixner
> >>> 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).
> >>
> >> I think everyone's had a chance to look over it by now. Thomas, shall I
> >> take the series?
> >
> > Yes please.
>
> Do you want a pull request? Or are you picking up the patches from the ML?
Did you pick up the Acked/Reviewed/Ignored-by tags?
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 00/26] genirq: fix use of irq_find_mapping outside of legal RCU context
[Dropping li...@openrisc.net from the CC list]
On 03/09/14 13:09, Thomas Gleixner wrote:
> On Wed, 3 Sep 2014, Jason Cooper wrote:
>
>> On Wed, Aug 27, 2014 at 10:33:44AM +0100, Marc Zyngier wrote:
>>> Hi Thomas,
>>>
>>> On Tue, Aug 26 2014 at 10:34:51 pm BST, Thomas Gleixner
>>> 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).
>>
>> I think everyone's had a chance to look over it by now. Thomas, shall I
>> take the series?
>
> Yes please.
Do you want a pull request? Or are you picking up the patches from the ML?
Thanks,
M.
--
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 00/26] genirq: fix use of irq_find_mapping outside of legal RCU context
On Wed, 3 Sep 2014, Jason Cooper wrote:
> On Wed, Aug 27, 2014 at 10:33:44AM +0100, Marc Zyngier wrote:
> > Hi Thomas,
> >
> > On Tue, Aug 26 2014 at 10:34:51 pm BST, Thomas Gleixner
> > 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).
>
> I think everyone's had a chance to look over it by now. Thomas, shall I
> take the series?
Yes please.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 00/26] genirq: fix use of irq_find_mapping outside of legal RCU context
On Wed, Aug 27, 2014 at 10:33:44AM +0100, Marc Zyngier wrote:
> Hi Thomas,
>
> On Tue, Aug 26 2014 at 10:34:51 pm BST, Thomas Gleixner
> 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).
I think everyone's had a chance to look over it by now. Thomas, shall I
take the series?
thx,
Jason.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 00/26] genirq: fix use of irq_find_mapping outside of legal RCU context
Hi Thomas,
On Tue, Aug 26 2014 at 10:34:51 pm BST, Thomas Gleixner
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).
Thanks,
M.
--
Jazz is not dead. It just smells funny.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 00/26] genirq: fix use of irq_find_mapping outside of legal RCU context
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?
Thanks,
tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
