From: Marc Zyngier <maz@kernel.org>
To: Thomas Gleixner <tglx@kernel.org>
Cc: Mayank Rungta <mrungta@google.com>,
Wim Van Sebroeck <wim@linux-watchdog.org>,
Guenter Roeck <linux@roeck-us.net>, Radu Rendec <radu@rendec.net>,
linux-watchdog@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-msm@vger.kernel.org,
"Kirill A. Shutemov" <kas@kernel.org>,
Douglas Anderson <dianders@chromium.org>
Subject: Re: [PATCH v3 1/5] genirq: Synchronize in-flight handlers during NMI teardown
Date: Fri, 04 Sep 2026 14:40:50 +0100 [thread overview]
Message-ID: <87wlt13zj1.wl-maz@kernel.org> (raw)
In-Reply-To: <87fqzp8jex.ffs@fw13>
On Fri, 04 Sep 2026 10:17:42 +0100,
Thomas Gleixner <tglx@kernel.org> wrote:
>
> On Wed, Sep 02 2026 at 18:54, Mayank Rungta wrote:
> > diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c
> > index 2fbff2618a1e..a9973b61163a 100644
> > --- a/kernel/irq/manage.c
> > +++ b/kernel/irq/manage.c
> > @@ -1379,6 +1379,14 @@ static bool irq_supports_nmi(struct irq_desc *desc)
> > if (d->chip->irq_bus_lock || d->chip->irq_bus_sync_unlock)
> > return false;
> >
> > + /*
> > + * NMIs cannot set IRQD_IRQ_INPROGRESS because they cannot acquire
> > + * spinlocks. Synchronous disable and teardown require querying the
> > + * hardware state via ->irq_get_irqchip_state().
> > + */
> > + if (!d->chip->irq_get_irqchip_state)
> > + return false;
> > +
> > return d->chip->flags & IRQCHIP_SUPPORTS_NMI;
> > }
> >
> > @@ -2034,11 +2042,20 @@ static const void *__cleanup_nmi(unsigned int irq, struct irq_desc *desc)
> > struct irqaction *action = NULL;
> > const char *devname = NULL;
> >
> > + guard(mutex)(&desc->request_mutex);
> > +
> > scoped_guard(raw_spinlock_irqsave, &desc->lock) {
> > - irq_nmi_teardown(desc);
> > + irq_settings_clr_disable_unlazy(desc);
> > + irq_shutdown(desc);
> > + }
> >
> > - desc->istate &= ~IRQS_NMI;
> > + /*
> > + * Ensure all in-flight NMI handlers on other CPUs complete before
> > + * clearing desc->action or tearing down NMI state.
> > + */
> > + __synchronize_hardirq(desc, true);
>
> NMIs are strictly per CPU interrupts. So how is this supposed to work
> correctly when looking at irqchip_state(ACTIVE) ?
>
> Marc?
I have no idea what this is trying to achieve.
This can only work for a global interrupt, not for a CPU-private
interrupt, since in general you can't observe the state of the
interrupt on another CPU.
My guess is that the OP is trying to trigger an NMI using a global
interrupt, which we never intended to be supported. That's not to say
that it cannot be supported, but this patch seems to be breaking the
core use case...
M.
--
Jazz isn't dead. It just smells funny.
next prev parent reply other threads:[~2026-09-04 13:38 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-03 1:54 [PATCH v3 0/5] watchdog: qcom: Support NMI pretimeout warnings Mayank Rungta
2026-09-03 1:54 ` [PATCH v3 1/5] genirq: Synchronize in-flight handlers during NMI teardown Mayank Rungta
2026-09-04 9:17 ` Thomas Gleixner
2026-09-04 13:40 ` Marc Zyngier [this message]
2026-09-04 14:34 ` Doug Anderson
2026-09-04 14:57 ` Marc Zyngier
2026-09-04 14:59 ` Doug Anderson
2026-09-04 15:11 ` Thomas Gleixner
2026-09-04 15:26 ` Doug Anderson
2026-09-03 1:54 ` [PATCH v3 2/5] genirq: Implement synchronous disable_nmi() Mayank Rungta
2026-09-03 1:54 ` [PATCH v3 3/5] genirq: Export NMI APIs Mayank Rungta
2026-09-04 9:29 ` Thomas Gleixner
2026-09-04 14:07 ` Doug Anderson
2026-09-04 15:05 ` Thomas Gleixner
2026-09-05 1:52 ` Mayank Rungta
2026-09-03 1:54 ` [PATCH v3 4/5] watchdog: pretimeout: Protect governor access with RCU for NMI safety Mayank Rungta
2026-09-03 1:54 ` [PATCH v3 5/5] watchdog: qcom: Register pretimeout interrupt as NMI Mayank Rungta
2026-09-03 8:18 ` Konrad Dybcio
2026-09-03 20:58 ` Mayank Rungta
2026-09-04 7:37 ` Konrad Dybcio
2026-09-04 14:37 ` Doug Anderson
2026-09-05 1:24 ` Mayank Rungta
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=87wlt13zj1.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=dianders@chromium.org \
--cc=kas@kernel.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-watchdog@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=mrungta@google.com \
--cc=radu@rendec.net \
--cc=tglx@kernel.org \
--cc=wim@linux-watchdog.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®