kthread_mod_delayed_work(9)

📦 version 7.3.1, in nixpkgs unstable

💅 kthread_mod_delayed_work(9) — from the Kernel API Manual, bestie

okay so picture this: you're deep in kernel land, you've got a kthread worker, you've got some delayed work, and you just wanna change the vibe of when it fires. that's this function. welcome 🫶

✨ NAME ✨

kthread_mod_delayed_work — modify delay of or queue a kthread delayed work

like, either you're rescheduling the timer on work that's already pending, or you're queueing it up fresh. lowkey iconic that it does both 💅

🌸 SYNOPSIS 🌸

bool kthread_mod_delayed_work (struct kthread_worker *worker , struct
kthread_delayed_work *dwork , unsigned long delay );

periodt. that's the whole signature. it returns a bool, so jot that down.

🎀 ARGUMENTS 🎀

  • worker — the kthread worker you're using. your main character worker, if you will 👑
  • dwork — the kthread delayed work you wanna queue up. this is the thing getting rescheduled 🦋
  • delay — how many jiffies to wait before queueing. yes, jiffies. not seconds, not vibes. jiffies ⏱️

💖 DESCRIPTION 💖

okay so here's the tea. if dwork is idle, this is literally equivalent to kthread_queue_delayed_work — same thing, no diff, slay.

otherwise? you're modifying dwork's timer so that it expires after delay. and bestie, if delay is zero, the work is guaranteed to be queued immediately. like, immediately immediately. no cap 🔥

now the messy part 🙈 — there's a special case when the work is being canceled in parallel. and yeah, that can happen either because of the real kthread_cancel_delayed_work_sync, or because of yet another kthread_mod_delayed_work call. it's giving chaos, honestly. so what do we do? we let the other command win and we return true here. that's it. the other one gets the crown 👑

and why does that matter? because that return value can be used for reference counting, and the number of queued works stays the same. so it's not just a random true, it's load-bearing. also, the caller is supposed to synchronize these operations a reasonable way — that's on you, not on this function, iykyk 😌

real talk: this function is safe to call from any context including IRQ handler. yes, even there. that's the whole point. if you want the deets, go peek at __kthread_cancel_work and kthread_delayed_work_timer_fn.

⭐ RETURN ⭐

  • false — if dwork was idle and queued
  • true — otherwise

flip a coin, but make it kernel code 🪙

🌈 SEE ALSO 🌈

all the siblings, the cousins, and the whole extended fam 💜 — and yes, the kernel file lives at ./kernel/kthread.c:

and that's the whole page, bestie 🧚 this one's shipped out of ./kernel, dated October 2026, and it's the kthread_mod_delayed_work(9) page from the Kernel API Manual 💅✨ mwah, go reschedule something responsibly 🍓

📦 where this page comes from