[PATCH 1/4] arm64: alternative: wait for other CPUs before patching

Catalin Marinas catalin.marinas at arm.com
Fri Dec 10 06:49:59 PST 2021


On Fri, Dec 03, 2021 at 10:47:20AM +0000, Mark Rutland wrote:
> In __apply_alternatives_multi_stop() we have a "really simple polling
> protocol" to avoid patching code that is concurrently executed on other
> CPUs. Secondary CPUs wait for the boot CPU to signal that patching is
> complete, but the boot CPU doesn't wait for secondaries to enter the
> polling loop, and it's possible that patching starts while secondaries
> are still within the stop_machine logic.
> 
> Let's fix this by adding a vaguely simple polling protocol where the
> boot CPU waits for secondaries to signal that they have entered the
> unpatchable stop function. We can use the arch_atomic_*() functions for
> this, as they are not patched with alternatives.
> 
> At the same time, let's make `all_alternatives_applied` local to
> __apply_alternatives_multi_stop(), since it is only used there, and this
> makes the code a little clearer.

Doesn't the stop_machine() mechanism wait for the CPUs to get in the
same state before calling our function or we need another stop at a
lower level in the arch code?

-- 
Catalin



More information about the linux-arm-kernel mailing list