task_work_add(9)
π task_work_add(9) β like, the manual page, bestie
okay so this one's from the Kernel API Manual, and it's genuinely one of those little functions that runs the whole vibe backstage. it's giving "hey bestie, can you run this for me later?" and honestly? obsessed. let's get into it π
β¨ NAME β¨
task_work_add β ask the @task to execute @work->func()
like literally just "hey you, run this callback when you get a sec" π«Ά
πΈ SYNOPSIS πΈ
int task_work_add (struct task_struct *task , struct callback_head *work
, enum task_work_notify_mode notify );
that's the whole signature, no cap. three args, returns an int. π
π ARGUMENTS π
taskβ the task which should run the callback. yes, that task. the one you're poking. πworkβ the callback to run. this is the thing you're handing over, the lil errand. πnotifyβ how to notify the targeted task. this one's the main character of the DESCRIPTION ngl, it decides how hard you're gonna nudge them. π₯
π¦ DESCRIPTION π¦
So the whole thing: you queue work for task_work_run (that's below, see SEE ALSO) and notify the task β but only if notify is TWA_RESUME, TWA_SIGNAL, TWA_SIGNAL_NO_IPI or TWA_NMI_CURRENT. those four, that's the list, periodt. β¨
okay let's break down the modes because the way each one behaves is genuinely different:
TWA_SIGNALβ works like signals, in that it will interrupt the targeted task and run the task_work, regardless of whether the task is currently running in the kernel or userspace. full send, no chill, it's getting done. β‘TWA_SIGNAL_NO_IPIβ works likeTWA_SIGNAL, except it doesn't send a reschedule IPI to force the targeted task to reschedule and run task_work. This can be advantageous if there's no strict requirement that the task_work be run as soon as possible, just whenever the task enters the kernel anyway. so like, lowkey chill mode. no rush bestie. πΈTWA_RESUMEβ work is run only when the task exits the kernel and returns to user mode, or before entering guest mode. patient vibes, waits for the right moment. π§TWA_NMI_CURRENTβ works likeTWA_RESUME, except it can only be used for the current task and if the current context is NMI. very specific, very exclusive, invite-only energy. π
Fails if the task is exiting/exited and thus it can't process this work. Otherwise work->func will be called when the task goes through one of the aforementioned transitions, or exits. π
If the targeted task is exiting, then an error is returned and the work item is not queued. It's up to the caller to arrange for an alternative mechanism in that case. β so like, plan B is your problem bestie, this function is not going to invent one for you π
π NOTE π
there is no ordering guarantee on works queued here. The task_work list is LIFO.
read that again. LIFO. last in, first out. so if you queue stuff expecting it in order... it's not giving that. at all. π«
β RETURN β
0 if succeeds or -ESRCH. that's it, that's the whole menu. slay. π
π SEE ALSO π
Kernel file ./kernel/task_work.c, and the whole friend group: task_work_cancel_match(9), task_work_cancel_func(9), task_work_cancel(9), task_work_run(9). go say hi, they're all in the same file. π
okay that's the whole page!! this one lives in ./kernel, and the date on it is October 2026 β so like, a lil time capsule moment. mwah, go queue some work, bestie π
β¨π
π¦ where this page comes from
- nixpkgs unstable: linux-manual 7.3.1
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash-1017 on : a language model's rewrite of the original, under its terms