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

[Thomas Gleixner]

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().

>> 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.

Thanks,

        tglx