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: 22+ 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 ` Mayank Rungta
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:32 ` Mayank Rungta
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:32 ` Mayank Rungta
2026-07-30 21:47 ` sashiko-bot
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-08-25 0:00 ` Mayank Rungta
2026-08-25 20:01 ` Thomas Gleixner
2026-07-30 21:32 ` [PATCH 3/3] watchdog: qcom: Register pretimeout interrupt as NMI Mayank Rungta via B4 Relay
2026-07-30 21:32 ` Mayank Rungta
2026-07-30 21:44 ` sashiko-bot
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 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.