On Thu, 14 Dec 2023 11:46:55 -0800
Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
> On Thu, 14 Dec 2023 at 09:53, Steven Rostedt <rostedt@xxxxxxxxxxx> wrote:
> >
> > + /*
> > + * For architectures that can not do cmpxchg() in NMI, or require
> > + * disabling interrupts to do 64-bit cmpxchg(), do not allow them
> > + * to record in NMI context.
> > + */
> > + if ((!IS_ENABLED(CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG) ||
> > + (IS_ENABLED(CONFIG_X86_32) && !IS_ENABLED(CONFIG_X86_CMPXCHG64))) &&
> > + unlikely(in_nmi())) {
> > + return NULL;
> > + }
>
> Again, this is COMPLETE GARBAGE.
>
> You're using "ARCH_HAVE_NMI_SAFE_CMPXCHG" to test something that just
> isn't what it's about.
For the 64-bit cmpxchg, on it isn't useful, but this code also calls normal
cmpxchg too. I had that part of the if condition as a separate patch, but
not for this purpose, but for actual architectures that do not support
cmpxchg in NMI. Those are broken here too, and that check fixes it.
>
> Having a NMI-safe cmpxchg does *not* mean that you actualyl have a
> NMI-safe 64-bit version.
Understood, but we also have cmpxchg in this path as well.
>
> You can't test it that way.
>
> Stop making random changes that just happen to work on the one machine
> you tested it on.
They are not random, but they are two different reasons. I still have the
standalone patch that adds the ARCH_HAVE_NMI_SAFE_CMPXCHG for the purpose
of not calling this code on architectures that do not support cmpxchg in
NMI, because if cmpxchg is not supported in NMI, then this should bail.
My mistake was to combine that change into this one which made it looks like
they are related, when in actuality they are not. Which is why there's a
"||" and not an "&&"
For this issue of the 64bit cmpxchg, is there any config that works for any
arch that do not have a safe 64-bit cmpxchg? At least for 486, is the
second half of the if condition reasonable?
if (IS_ENABLED(CONFIG_X86_32) && !IS_ENABLED(CONFIG_X86_CMPXCHG64)) {
if (unlikely(in_nmi()))
return NULL;
}
?
-- Steve
