timer_delete_sync(9)

💅 timer_delete_sync 💅

okay so this is a page from the Kernel API Manual (the timer_delete_sync(9) one, yes bestie, the 9 is the section, we don't ask questions) and it's genuinely so good. it's about deactivating a timer and waiting for the handler to finish. like, both. at once. main character energy fr fr 🎀

---

✨ NAME ✨

timer_delete_sync — deactivate a timer and wait for the handler to finish. that's it. that's the whole vibe. 💖

---

✨ SYNOPSIS ✨

int timer_delete_sync (struct timer_list *timer );

---

✨ ARGUMENTS ✨

• timer — the timer you're deactivating. the one. your little guy. 🕐

---

✨ DESCRIPTION ✨

ngl the synchronization rules here are a lot, so let's do this properly. 🔥

Callers must prevent restarting of the timer — otherwise this function is literally meaningless, no cap. It must not be called from interrupt contexts unless the timer is an irqsafe one. The caller must not hold locks which would prevent completion of the timer's callback function. And the timer's handler must not call add_timer_on. 🚫

Upon exit, the timer is not queued and the handler is not running on any CPU. clean. ✨

For !irqsafe timers, the caller must not hold locks that are held in interrupt context. Even if the lock has nothing to do with the timer in question. like, at all. and here's why, bestie:

CPU0                             CPU1
----                             ----
                                 <SOFTIRQ>
                                   call_timer_fn;
                                   base->running_timer = mytimer;
spin_lock_irq(somelock);
                                 <IRQ>
                                    spin_lock(somelock);
timer_delete_sync(mytimer);
while (base->running_timer == mytimer);

so now timer_delete_sync will never return and never release somelock. 💀 The interrupt on the other CPU is waiting to grab somelock, but it has interrupted the softirq that CPU0 is waiting to finish. deadlock city. population: you. 😭

⚠️ This function cannot guarantee that the timer is not rearmed again by some concurrent or preempting code, right after it dropped the base lock. If there is the possibility of a concurrent rearm then the return value of the function is meaningless. 🙈

If such a guarantee is needed — e.g. for teardown situations — then use timer_shutdown_sync instead. periodt. 👑

---

✨ RETURN ✨

• 0 — the timer was not pending
• 1 — the timer was pending and deactivated

slay, binary. 🦋

---

✨ SEE ALSO ✨

Kernel file ./kernel/time/timer.c struct timer_base(9), __round_jiffies_relative(9), round_jiffies(9), round_jiffies_relative(9), __round_jiffies_up_relative(9), round_jiffies_up(9), round_jiffies_up_relative(9), timer_init_key(9), mod_timer_pending(9), mod_timer(9), timer_reduce(9), add_timer(9), add_timer_local(9), add_timer_global(9), add_timer_on(9), __timer_delete(9), timer_delete(9), timer_shutdown(9), __try_to_del_timer_sync(9), timer_delete_sync_try(9), __timer_delete_sync(9), timer_shutdown_sync(9), fetch_next_timer_interrupt_remote(9), timer_unlock_remote_bases(9), timer_lock_remote_bases(9), timer_base_is_idle(9), timer_expire_remote(9), get_next_timer_interrupt(9), timer_base_try_to_set_idle(9), timer_clear_idle(9), __run_timers(9)

that's a whole friend group right there, go say hi to all of them. 🫶

---

<div align="center">🌸 from ./kernel/time, dated October 2026, and yes the page is literally called timer_delete_sync(9) — mwah, bye bestie 💜🧚‍♀️</div>