linux-kernel - Re: [PATCH 1/7] stop_machine: Introduce stop_machine

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20260128163556.GOaXo67MJ43kCRs68m@fat_crate.local>
Date: Wed, 28 Jan 2026 17:35:56 +0100
From: Borislav Petkov <bp@...en8.de>
To: "Kaplan, David" <David.Kaplan@....com>
Cc: "Chang S. Bae" <chang.seok.bae@...el.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"x86@...nel.org" <x86@...nel.org>,
	"tglx@...utronix.de" <tglx@...utronix.de>,
	"mingo@...hat.com" <mingo@...hat.com>,
	"dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
	"peterz@...radead.org" <peterz@...radead.org>
Subject: Re: [PATCH 1/7] stop_machine: Introduce stop_machine_nmi()

On Wed, Jan 28, 2026 at 01:31:44AM +0000, Kaplan, David wrote:
> Ok, that's what I thought you were suggesting.  But as I noted, I don't
> think that works if CONFIG_SMP=n because stop_machine.c isn't built.
> 
> I think you could fix this by adding an #ifdef CONFIG_SMP in the header and
> a dummy definition of stop_machine_nmi_handler_enabled in that case, but is
> it worth adding another #ifdef/#else/#endif just to move the static key
> declaration?

That's already there:

#else	/* CONFIG_SMP || CONFIG_HOTPLUG_CPU */
...

static __always_inline bool stop_machine_nmi_handler_enabled(void)
{
        return false;
}

:-)

That's the usual pattern with those things.

But we might not need it anymore.

> I think that can also work, but just curious why that would be preferred?

Simpler code.

> It seems very similar in theory (test a bit to see if the handler hasn't
> been run yet on this cpu and if so clear it and run the handler).  It might
> be slightly less memory usage (I think) but creates more cache contention
> with every core trying to modify the one nmi_cpumask value.

We don't care about performance with stomp_machine, right? It is a big fat
hammer and bouncing a cacheline in the face of NMIs firing on every core is
probably meh...

> And while the perf of any stop machine isn't meant to be the best, we still
> don't want the NMI handler to run longer than it has to and having hundreds
> of cores fighting over the same cacheline to clear their bit doesn't seem
> ideal.

I'd say let's make the simplest variant work first and then go optimize it.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette