wait_var_eve...nterruptible(9)

📦 version 7.3.1, in nixpkgs unstable

💤 wait_var_event_interruptible — kernel API manual ✨

okay so bestie, we're in the Linux kernel API manual, section 9, and the page is literally called wait_var_eve...nterruptible(9) (yes the title itself got truncated, it's giving "my name is too long for the header" 😭). Anyway. Sit down, grab a boba, we're learning to wait. 🧚

🌸 NAME 🌸

wait_var_event_interruptible — wait for a variable to be updated and notified 💖

✨ SYNOPSIS ✨

wait_var_event_interruptible (var , condition );

🎀 ARGUMENTS 🎀

  • var — the address of the variable being waited on 👀
  • condition — the condition to wait for ⭐

💅 DESCRIPTION 💅

So here's the vibe: you wait for a condition to be true or a signal to be received. That's it, that's the whole personality. 🫶

But here's the cute little detail — it only re-checks the condition when a wake up is received for the given var. And var is an arbitrary kernel address which need not be directly related to the given condition, but usually is. iykyk. No cap, it can literally be any address, it's just usually the sensible one. 🙈

This is similar to wait_var_event but — and this is the main character moment — it returns a value:

  • 0 if the condition became true 🎉
  • -ERESTARTSYS if a signal was received 😭
lowkey important: the condition should normally use smp_load_acquire or a similarly ordered access, so that any changes to memory made before the condition became true will be visible after the wait completes. Don't skip the ordering, bestie, that's how you get haunted bugs 💀

🔥 SEE ALSO 🔥

Kernel file ./include/linux/wait_bit.h and the whole wait_bit extended universe 👑

and that's the page, bestie!! 🌈 it lives in ./include/linux, dated October 2026, and it's filed under wait_var_eve...nterruptible(9) — slay, go wake up some variables 💜🦋

📦 where this page comes from