find_worker_executing_work(9)

📦 version 7.3.1, in nixpkgs unstable

💅 find_worker_executing_work — a.k.a. "who's holding my work item rn"

okay so bestie, this one's from the Kernel API Manual (the find_worker_executing_work(9) page), and it's genuinely one of the more unhinged little corner cases in the workqueue code. Let's get into it 🫶

✨ NAME ✨

find_worker_executing_work — find worker which is executing a work

like, literally that. we're playing detective 🔍 for a worker thread.

🌸 SYNOPSIS 🌸

struct worker * find_worker_executing_work (struct worker_pool *pool ,
struct work_struct *work );

two args, one pointer back. no cap. ✨

🎀 ARGUMENTS 🎀

  • pool — pool of interest. the pool you're snooping on 💅
  • work — work to find worker for. the work item whose worker you're looking for

🦋 DESCRIPTION 🦋

So the whole vibe of this function is: find a worker that's executing work on pool, and it does that by searching pool->busy_hash, which is keyed by the address of work. 🗂️

But here's the thing — for a worker to actually match, two things gotta line up: its current execution should match the address of work, and its work function. Both. That second check is the whole point, and it's there to avoid unwanted dependency between unrelated work executions caused by a work item being recycled while it's still being executed. yes, recycled. like a thrifted top but make it memory 💀

This is a bit tricky, fr fr. Let me explain, because it's giving "why is this so cursed":

A work item may be freed once its execution starts, and nothing prevents the freed area from being recycled for another work item. So if the same work item address ends up being reused before the original execution finishes, workqueue will identify the recycled work item as currently executing — and make it wait until the current execution finishes. which introduces an unwanted dependency. 🙈

Enter this function: it checks the work item address and the work function to avoid false positives.

⚠️ Note that this isn't complete — one may construct a work function which can introduce dependency onto itself through a recycled work item. Well, if somebody wants to shoot oneself in the foot that badly, there's only so much we can do 😭 and if such deadlock actually occurs, it should be easy to locate the culprit work function. go off, detective 🔥

👑 CONTEXT 👑

raw_spin_lock_irq(pool->lock).

(read: have that lock held, bestie. it's not a suggestion 💅)

⭐ RETURN ⭐

Pointer to worker which is executing work if found, NULL otherwise.

that's it. found = worker pointer, not found = NULL. slay. ✨

🌈 SEE ALSO 🌈

Kernel file ./kernel/workqueue.c, plus literally the entire workqueue cinematic universe 🍿 — here's the full guest list, every single one, no skips:

and that's the whole page, bestie 💖 this gem lives in ./kernel and it's dated October 2026 — so like, future-dated icon behavior 👑 go read workqueue.c and stan a worker. periodt. 🧚✨

📦 where this page comes from