STRUCT BPF_CPUMASK(9)

📦 version 7.3.1, in nixpkgs unstable

💖 struct bpf_cpumask(9) — the refcounted BPF cpumask wrapper, bestie edition 💖

okay so real talk, this is struct bpf_cpumask(9) from the Kernel API Manual, and it's giving tiny struct, big responsibilities. Let me tell you everything, no cap.

✨ NAME ✨

struct bpf_cpumask — a refcounted BPF cpumask wrapper structure. that's it, that's the vibe 🫶

🎀 SYNOPSIS 🎀

struct bpf_cpumask {
    cpumask_t cpumask;
    refcount_t usage;
 };

literally two fields, and yet she's iconic 👑

🌸 Members 🌸

  • cpumask — the actual cpumask embedded in the struct. she's the whole point, honestly 💅
  • usage — the object reference counter. the way this works: when the refcount goes to 0, the memory is released back to the BPF allocator, which provides RCU safety. so like, when nobody's holding on anymore, she goes home 🦋

💜 Description 💜

okay so here's the tea, and it's a whole design decision: we explicitly embed a cpumask_t rather than a cpumask_var_t. why? because the typedef of cpumask_var_t changes depending on whether CONFIG_CPUMASK_OFFSTACK is defined or not, and that would confuse the verifier. not the verifier getting confused 😭 so it's done deliberately. check the details in <linux/cpumask.h> if you want the full lore, iykyk.

the consequence (and yes, there is a consequence, bestie): this structure is likely a bit larger than it needs to be when CONFIG_CPUMASK_OFFSTACK is defined, because it embeds the whole NR_CPUS-size bitmap. but ngl, the extra memory overhead is minimal. and for the more typical case of CONFIG_CPUMASK_OFFSTACK not being defined, the structure is the same size regardless. slay 🌈

🔥 SEE ALSO 🔥

start with the kernel file: ./kernel/bpf/cpumask.c, then the whole friend group:

and that's the whole page, bestie!! this little fairy 🧚 came to you from ./kernel/bpf, dated October 2026, and yes she's still listed under struct bpf_cpumask(9) at the bottom like the main character she is 💖✨🎀

📦 where this page comes from