register_restart_handler(9)

💅 register_restart_handler(9) — like, the Kernel API Manual one 🎀

okay bestie, so this is from the Kernel API Manual and it's literally about telling the kernel who gets to hit the big red restart button 🔥 buckle up, this one's short but it's got LORE.

---

✨ NAME ✨

register_restart_handler — registering a function that's gonna get called to reset the whole entire system, no cap 🫶

---

🦋 SYNOPSIS 🦋

int register_restart_handler (struct notifier_block *nb );

---

🌸 ARGUMENTS 🌸

• nb — all the info about the handler function that's gonna get called, bestie. And specifically: nb->priority is the handler priority, and handlers really should follow these guidelines when they're setting priorities 👇
  • 0 — the restart handler of last resort, with limited restart capabilities. like, it's the backup of the backup 💀
  • 128 — the default restart handler; use this one if no other restart handler is expected to be available, and/or if the restart functionality is sufficient to restart the entire system. solid middle-of-the-road queen 👑
  • 255 — the highest priority restart handler, and it will literally preempt all other restart handlers. main character energy fr fr ✨

---

💖 DESCRIPTION 💖

So what this does: it registers a function — with actual code in it — that's gonna be called to restart the system. simple as that, slay.

Registered functions get called from machine_restart as, like, the last step of the restart sequence (that's if the architecture-specific machine_restart function calls do_kernel_restart — see below for the details 👀). And registered functions are expected to restart the system immediately. no dawdling. If more than one function is registered, the restart handler priority is what selects which function gets called first 🏁

Restart handlers are expected to be registered from non-architecture code — typically from drivers. A typical use case would be a system where the restart functionality is provided through a watchdog 🐕 Multiple restart handlers may exist; for example, one restart handler might restart the entire system, while another one only restarts the CPU. In cases like that, the restart handler that only restarts part of the hardware is expected to register with low priority so we can be sure it only runs if no other means to restart the system is available. like, stay in your lane, king 💅

Currently this always returns zero, because atomic_notifier_chain_register always returns zero. literally always. that's just how it is 🙈

---

🧚 SEE ALSO 🧚

Kernel file ./kernel/reboot.c, plus the whole squad:

emergency_restart(9), register_reboot_notifier(9), unregister_reboot_notifier(9), unregister_restart_handler(9), do_kernel_restart(9), kernel_restart(9), kernel_halt(9), register_sys_off_handler(9), unregister_sys_off_handler(9), devm_register_sys_off_handler(9), devm_register_power_off_handler(9), devm_register_restart_handler(9), register_platform_power_off(9), unregister_platform_power_off(9), do_kernel_power_off(9), kernel_can_power_off(9), kernel_power_off(9), orderly_poweroff(9), orderly_reboot(9), hw_failure_emergency_action_func(9), hw_failure_emergency_schedule(9), __hw_protection_trigger(9)

---

and that's the whole page, bestie!! 🍓 before you go — this icon lives in ./kernel and it's dated October 2026, so like… future queen behavior honestly 💜💫 go restart something (responsibly) 🎀