Re: [PATCH v3 3/5] genirq: Export NMI APIs

[Mayank Rungta]

On Fri, Sep 4, 2026 at 8:05 AM Thomas Gleixner <tglx@xxxxxxxxxx> wrote:
>
> On Fri, Sep 04 2026 at 07:07, Doug Anderson wrote:
> > On Fri, Sep 4, 2026 at 2:29 AM Thomas Gleixner <tglx@xxxxxxxxxx> wrote:
> >> On Wed, Sep 02 2026 at 18:54, Mayank Rungta wrote:
> >> > Currently, request_nmi(), free_nmi(), enable_nmi(), disable_nmi_nosync(),
> >> > and disable_nmi() are restricted to built-in kernel code because they are
> >> > not exported.
> >> >
> >> > Export these symbols with EXPORT_SYMBOL_GPL so loadable kernel modules can
> >> > register and manage NMIs.
> >>
> >> I'm not really fond of that.
> >
> > Is this to be taken a NAK on the whole idea, then?
> >
> > The last patch in the series [1] wants to promote a HW watchdog bark
> > interrupt to NMI. This seems like a pretty useful thing to do and an
> > appropriate use of NMI, but the HW watchdog driver is a kernel module.
> > Do you have another suggestion for solving that?
>
> I understand the intent and why it might be a good idea, but letting
> random modules convert interrupts into NMIs is a scary thought.
>
> We can export it in a restricted way though to limit the exposure and
> force people to go through a thorough review of these use cases.
>
> That could be a subsystem restricted export or an explicit restriction
> via EXPORT..FOR_MODULES().
>

That makes sense. Do you have a preference between
`EXPORT_SYMBOL_NS_GPL(..., WATCHDOG)` and
`EXPORT_SYMBOL_FOR_MODULES(..., "qcom_wdt")`? Happy to go with
whichever you prefer for v4 (which I'll hold off on sending until we
reach an agreement on the NMI teardown discussion in patch 1).

> >> Funny enough there is already a driver which claims it can be built as
> >> module which uses these interfaces. Oh well...
> >>
> >> > Assisted-by: Antigravity:gemini
> >>
> >> I'm impressed that AI is required to add four EXPORT_SYMBOL_GPL()
> >> instances.
> >
> > Hmm, I guess it's hard to figure out the guidance here. I think Mayank
> > is only adding this tag to try match what's documented in
> > `coding-assistants.rst`. If you've got an AI helping you with a
> > series, it's pretty much touching all the patches. I guess you're
> > suggesting that, even if AI touched it, trivial patches should remove
> > the tag?
>
> I really have no strong opinion about it. But it just amused me and I
> couldn't help my self from commenting.
>

Actually, I was able to add the first 4 exports by myself, it was the
5th one I really needed help with! :)

Jokes aside, since the whole series went through AI review and
different maintainers have different expectations around AI
attribution right now, I conservatively added the tag across all
patches. I'll drop `Assisted-by:` from trivial patches like this in
the next revision.

Thanks,
Mayank