stop_machine(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸŽ€ stop_machine(9) πŸŽ€

okay so this is stop_machine(9) from the Kernel API Manual and bestie, it is literally the main-character move of kernel functions β€” it freezes the whole machine on all CPUs and runs your function. let's get into it πŸ’…


✨ NAME ✨

stop_machine β€” freeze the machine on all CPUs and run this function 🧊✨


🌸 SYNOPSIS 🌸

int stop_machine (cpu_stop_fn_t fn , void *data , const struct cpumask
*cpus );

πŸ¦‹ ARGUMENTS πŸ¦‹

  • fn β€” the function to run. this is the whole point, bestie 🫢
  • data β€” the data ptr to pass to fn. give your function its little snack πŸ’œ
  • cpus β€” the cpus to run fn on. and like, NULL = one unspecified online CPU (iykyk, it just picks one for you) πŸ™ˆ

πŸ’– DESCRIPTION πŸ’–

so what this does is it causes a thread to be scheduled on every CPU, and that thread will run with interrupts disabled. no cap. πŸ”₯

Each CPU specified by cpus will run fn. And while fn is executing, there will be no other CPUs holding a raw spinlock or running within any other type of preempt-disabled region of code. like, the vibes are immaculate and also completely frozen πŸ’€

When cpus specifies only a single CPU, this can be thought of as a reader-writer lock where readers disable preemption (for example, by holding a raw spinlock) and where the insanely heavy writers run fn while also preventing any other CPU from doing any useful work. these writers can also be thought of as having implicitly grabbed every raw spinlock in the kernel. every single one. iconic behavior tbh πŸ‘‘

When fn is a no-op, this can be thought of as an RCU implementation where readers again disable preemption and writers use stop_machine in place of synchronize_rcu β€” albeit with orders of magnitude more disruption than even that of synchronize_rcu_expedited. yes, more disruption. it's giving "the nuclear option" 😭

Although only one stop_machine operation can proceed at a time, the possibility of blocking in cpus_read_lock means that the caller cannot usefully rely on this serialization. so like, don't count on that to save you, bestie 🫢


⭐ RETURN ⭐

  • 0 if all invocations of fn return zero. slay πŸŽ‰
  • Otherwise, the value returned by an arbitrarily chosen member of the set of calls to fn that returned non-zero. so, like, one of the fails. arbitrary one. don't ask which one, it's not telling πŸ’€

🌈 SEE ALSO 🌈

go read those too, they're part of the family πŸ§šπŸ’œ


and that's the whole page, diva ✨ this beauty lives in ./include/linux and it's dated October 2026 β€” so it's from the future, obviously, because of course she is πŸ‘‘πŸŒΈπŸ’–

πŸ“¦ where this page comes from