[QUESTION] NMI: Understanding ARCH_HAVE_NMI_SAFE_CMPXCHG usage

[Leo Liang <ycliang@andestech.com>]

Hi everyone,

I came across the `ARCH_HAVE_NMI_SAFE_CMPXCHG` definition recently
and could not fully understand how an architecture indicates its support for it.

From my initial review of the code,
it seems to indicate whether a compare-exchange operation is safe
within an NMI context (handler) without causing a deadlock or other issues.

I have checked the initial commit and the architectures that enabled this config
with that commit. My inference is that if an architecture implements cmpxchg
with a lockless algorithm, it should be able to enable this config.

The reason is that I can only think of one constraint: "taking a lock"
should be avoided in an NMI context in case the NMI encounters a deadlock.
Therefore, if the architecture does not use interrupt masking and locking algorithm
to implement cmpxchg then it should be safe for the architecture to enable this config.

However, PARISC implements cmpxchg using interrupt masking and a while loop[1],
and `ARCH_HAVE_NMI_SAFE_CMPXCHG` is also enabled for this architecture, so I am
unsure if my inference is valid.

Could someone please clarify the specific implications of this definition
and in which scenarios it becomes particularly critical? Are there
any specific hardware capabilities or kernel architecture-specific APIs
that govern its presence or absence?

I've searched lore.kernel.org and kernel documentation for a detailed
explanation of `ARCH_HAVE_NMI_SAFE_CMPXCHG`'s history and current
usage guarantees, but haven't found a definitive overview.

Any pointers or explanations would be greatly appreciated.

[1] https://github.com/torvalds/linux/blob/master/arch/parisc/lib/bitops.c#L59

Thanks,
Leo