Re: [PATCH 2/3] genirq: Export NMI APIs

[Mayank Rungta]

On Fri, Aug 7, 2026 at 9:00 AM Thomas Gleixner <tglx@xxxxxxxxxx> wrote:
>
> On Fri, Jul 31 2026 at 16:18, Doug Anderson wrote:
> > On Thu, Jul 30, 2026 at 3:55 PM Guenter Roeck <linux@xxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx/
> >
> > 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).
>

Hi Thomas,

Friendly ping on this thread!

I completely understand maintainer schedules are very busy. If you
haven't had a chance to look at this by the end of the week, I'm happy
to take a stab at implementing the NMI teardown synchronization in v2
myself for your review.

Please let me know if you have any thoughts or guidance on the approach.

Thanks,
Mayank