From: Thomas Gleixner <tglx@kernel.org>
To: Doug Anderson <dianders@chromium.org>,
Guenter Roeck <linux@roeck-us.net>
Cc: mrungta@google.com, Wim Van Sebroeck <wim@linux-watchdog.org>,
linux-watchdog@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-msm@vger.kernel.org,
"Kirill A. Shutemov" <kas@kernel.org>
Subject: Re: [PATCH 2/3] genirq: Export NMI APIs
Date: Fri, 07 Aug 2026 18:00:16 +0200 [thread overview]
Message-ID: <87h5l5ex9r.ffs@fw13> (raw)
In-Reply-To: <CAD=FV=XuCHdOv8kct63JzmbgjxJMxL7fc75KtAQL0hbJc7_v0w@mail.gmail.com>
On Fri, Jul 31 2026 at 16:18, Doug Anderson wrote:
> On Thu, Jul 30, 2026 at 3:55 PM Guenter Roeck <linux@roeck-us.net> wrote:
>> > This seems reasonable to me. One thought I had was that we could
>> > possibly get by with fewer exported symbols by changing
>> > disable_nmi_nosync() and enable_nmi() to "static inline" functions in
>> > the header file. That being said, what Mayank has here feels slightly
>> > better to me.
>> >
>>
>> I don't claim to understand the NMI APIs used, but Sashiko's feedback
>> seems real to me. Someone who knows that code will need to confirm that
>> there are no unexpected pitfalls.
>
> Since Sashiko doesn't reply-to all, here's a link to its feedback:
>
> https://lore.kernel.org/all/20260730214758.DBD5E1F000E9@smtp.kernel.org/
>
> Indeed, it does look like legitimate feedback. While the problems are
> pre-existing, it is true that exporting as a module could widen the
> exposure because the code backing the NMI handler could now be
> unloaded.
>
> I did a little bit of AI analysis of the problem myself. As far as I
> can tell, it would be relatively safe to implement a synchronous
> "disable_nmi" by just calling "disable_irq", much like is done for
> other NMI functions. The caveat here is that it would only be safe on
> IRQ controllers that provided irq_get_irqchip_state(). This is because
> on NMI we don't set IRQD_IRQ_INPROGRESS and thus
> __synchronize_hardirq() will fall back to calling
> __irq_get_irqchip_state(). If any controllers supported NMI but
> _didn't_ support irq_get_irqchip_state(), we'd silently skip waiting
> for NMI completion. Maybe we could simply make it illegal for a
> controller to support NMI without irq_get_irqchip_state()?
>
> I guess maybe we need Thomas Gleixner to weigh in on this? Thomas:
> should this issue block Mayank's patch? Would you expect him to
> propose fixes as part of his series, or is this something you'd prefer
> to post patches for yourself?
Sorry, I did not pay attention as I was AFK and busy with bugs. I'll
have a look once the dust settles on my side (hopefully soonish).
Thanks,
tglx
next prev parent reply other threads:[~2026-08-07 16:00 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-30 21:32 [PATCH 0/3] watchdog: qcom: Support NMI pretimeout warnings Mayank Rungta via B4 Relay
2026-07-30 21:32 ` [PATCH 1/3] watchdog: pretimeout: Protect governor access with RCU for NMI safety Mayank Rungta via B4 Relay
2026-07-30 21:46 ` Doug Anderson
2026-08-07 5:34 ` Guenter Roeck
2026-07-30 21:32 ` [PATCH 2/3] genirq: Export NMI APIs Mayank Rungta via B4 Relay
2026-07-30 21:49 ` Doug Anderson
2026-07-30 22:55 ` Guenter Roeck
2026-07-31 23:18 ` Doug Anderson
2026-08-07 16:00 ` Thomas Gleixner [this message]
2026-07-30 21:32 ` [PATCH 3/3] watchdog: qcom: Register pretimeout interrupt as NMI Mayank Rungta via B4 Relay
2026-07-30 21:52 ` Doug Anderson
2026-07-31 11:56 ` Konrad Dybcio
2026-07-31 14:12 ` Guenter Roeck
2026-07-31 23:54 ` 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=87h5l5ex9r.ffs@fw13 \
--to=tglx@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=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