From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
To: Lukas Wunner <lukas@wunner.de>
Cc: Thomas Gleixner <tglx@linutronix.de>,
Marc Zyngier <maz@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Jakub Kicinski <kuba@kernel.org>,
Linus Walleij <linus.walleij@linaro.org>,
Bartosz Golaszewski <brgl@bgdev.pl>,
linux-gpio@vger.kernel.org,
Octavian Purdila <octavian.purdila@nxp.com>,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] genirq: Deduplicate WARN_ON_ONCE() in generic_handle_domain_irq()
Date: Mon, 16 May 2022 08:29:50 +0200 [thread overview]
Message-ID: <YoHvXpo8PJUDbs08@linutronix.de> (raw)
In-Reply-To: <c3caf60bfa78e5fdbdf483096b7174da65d1813a.1652168866.git.lukas@wunner.de>
On 2022-05-10 09:56:05 [+0200], Lukas Wunner wrote:
> An example for irqchips where the warning is false positive are
> USB-attached GPIO controllers such as drivers/gpio/gpio-dln2.c:
They are not false positives because…
> USB gadgets are incapable of directly signaling an interrupt because
> they cannot initiate a bus transaction by themselves. All communication
> on the bus is initiated by the host controller, which polls a gadget's
> Interrupt Endpoint in regular intervals. If an interrupt is pending,
> that information is passed up the stack in softirq context, from which
> a hardirq is synthesized via generic_handle_domain_irq().
they tell you that the context is wrong. From looking at gpio-dln2
this is called from USB URB's callback which is softirq. In the end
dln2_gpio_event() is invoked while dln2_dev::event_cb_lock is acquired.
That lock is acquired by disabling interrupts which is what gets the
locking right for generic_handle_domain_irq(). If that lock lifted to
spin_lock_bh() (because it is always in urb's calback context and all
HCDs complete in one context unlike now) then this breaks. And
PREEMPT_RT is broken already. Therefore, last week, I've been promoting
generic_handle_domain_irq_safe()
https://lkml.kernel.org/r/YnkfWFzvusFFktSt@linutronix.de
and sadly I missed dln2. Please let me know if you have more users
similar to dln2. I will add those to my list once upstream buys that
interface.
Sebastian
WARNING: multiple messages have this Message-ID (diff)
From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
To: Lukas Wunner <lukas@wunner.de>
Cc: Thomas Gleixner <tglx@linutronix.de>,
Marc Zyngier <maz@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Jakub Kicinski <kuba@kernel.org>,
Linus Walleij <linus.walleij@linaro.org>,
Bartosz Golaszewski <brgl@bgdev.pl>,
linux-gpio@vger.kernel.org,
Octavian Purdila <octavian.purdila@nxp.com>,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] genirq: Deduplicate WARN_ON_ONCE() in generic_handle_domain_irq()
Date: Mon, 16 May 2022 08:29:50 +0200 [thread overview]
Message-ID: <YoHvXpo8PJUDbs08@linutronix.de> (raw)
In-Reply-To: <c3caf60bfa78e5fdbdf483096b7174da65d1813a.1652168866.git.lukas@wunner.de>
On 2022-05-10 09:56:05 [+0200], Lukas Wunner wrote:
> An example for irqchips where the warning is false positive are
> USB-attached GPIO controllers such as drivers/gpio/gpio-dln2.c:
They are not false positives because…
> USB gadgets are incapable of directly signaling an interrupt because
> they cannot initiate a bus transaction by themselves. All communication
> on the bus is initiated by the host controller, which polls a gadget's
> Interrupt Endpoint in regular intervals. If an interrupt is pending,
> that information is passed up the stack in softirq context, from which
> a hardirq is synthesized via generic_handle_domain_irq().
they tell you that the context is wrong. From looking at gpio-dln2
this is called from USB URB's callback which is softirq. In the end
dln2_gpio_event() is invoked while dln2_dev::event_cb_lock is acquired.
That lock is acquired by disabling interrupts which is what gets the
locking right for generic_handle_domain_irq(). If that lock lifted to
spin_lock_bh() (because it is always in urb's calback context and all
HCDs complete in one context unlike now) then this breaks. And
PREEMPT_RT is broken already. Therefore, last week, I've been promoting
generic_handle_domain_irq_safe()
https://lkml.kernel.org/r/YnkfWFzvusFFktSt@linutronix.de
and sadly I missed dln2. Please let me know if you have more users
similar to dln2. I will add those to my list once upstream buys that
interface.
Sebastian
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2022-05-16 6:29 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-10 7:56 [PATCH] genirq: Deduplicate WARN_ON_ONCE() in generic_handle_domain_irq() Lukas Wunner
2022-05-10 7:56 ` Lukas Wunner
2022-05-16 6:29 ` Sebastian Andrzej Siewior [this message]
2022-05-16 6:29 ` Sebastian Andrzej Siewior
2022-05-16 6:53 ` Thomas Gleixner
2022-05-16 6:53 ` Thomas Gleixner
2022-05-16 7:02 ` Sebastian Andrzej Siewior
2022-05-16 7:02 ` Sebastian Andrzej Siewior
2022-05-16 10:04 ` Lukas Wunner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YoHvXpo8PJUDbs08@linutronix.de \
--to=bigeasy@linutronix.de \
--cc=brgl@bgdev.pl \
--cc=kuba@kernel.org \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lukas@wunner.de \
--cc=mark.rutland@arm.com \
--cc=maz@kernel.org \
--cc=octavian.purdila@nxp.com \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.