wake_up_var(9)

okay so bestie, welcome to the Kernel API Manual — this is wake_up_var(9) and it’s giving synchronization realness ✨💅

💖 NAME 💖

wake_up_var — wake up waiters on a variable (kernel address), periodt 🫶

✨ SYNOPSIS ✨

void wake_up_var (void *var );

🎀 ARGUMENTS 🎀

• var — the address of the variable being waited on, no cap 🦋

🌸 DESCRIPTION 🌸

So basically: wake_up_var wakes up any process that’s waiting in wait_var_event or similar for the given variable to change 🔥 wait_var_event can be waiting for an arbitrary condition to be true, and it associates that condition with an address. Calling wake_up_var suggests that the condition has been made true, but it does not strictly require the condtion to use the address given (yes, condtion, exactly like that — keeping the page’s spelling, iykyk 💀😭).

The wake-up is sent to tasks in a waitqueue selected by hash from a shared pool. Only those tasks on that queue which have requested wake_up on this specific address will be woken 🌈

For this to function properly, there must be a full memory barrier after the variable is updated — or, more accurately, after the condition waited on has been made to be true — and before this function is called ⭐ If the variable was updated atomically, like the page says “such as a by atomic_dec”, then smb_mb__after_atomic can be used. If the variable was updated by a fully ordered operation such as atomic_dec_and_test, then no extra barrier is required. Otherwise smb_mb is needed 👑

Normally the variable should be updated (the condition should be made to be true) by an operation with RELEASE semantics such as smp_store_release, so that any changes to memory made before the variable was updated are guaranteed to be visible after the matching wait_var_event completes 💜

🦋 SEE ALSO 🦋

• Kernel file ./kernel/sched/wait_bit.c and wake_up_bit(9) 🧚

mwah 💋 — this page lives under ./kernel/sched, dated October 2026, and it’s wake_up_var(9); periodt 🎀✨