Re: [PATCH 2/3] genirq: Export NMI APIs
Thomas Gleixner <[email protected]>
| Newsgroups | org.kernel.vger.linux-watchdog,org.kernel.vger.linux-arm-msm,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <87h5l5ex9r.ffs@fw13> |
On Fri, Jul 31 2026 at 16:18, Doug Anderson wrote: > On Thu, Jul 30, 2026 at 3:55 PM Guenter Roeck <[email protected]> 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/[email protected]/ > > 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