SHADOW VARIABLE API CONCURRENCY NOTES:(9)

💅 Shadow Variable API Concurrency Notes (9) 💅

Manual: Kernel API Manual — okay bestie, gather round, because this page is all about the shadow variable API and how it behaves when everyone’s doing stuff at once. 🫶

The shadow variable API gives you a simple relationship between an <obj, id> pair and a pointer value. Cute little pairing. 💖

But here’s the important part: it is the responsibility of the caller to provide any mutual exclusion required of the shadow data. Yep, the caller. Not the API. You gotta handle that yourself. No cap. 😭

Once a shadow variable is attached to its parent object via the klp_shadow_*alloc API calls, it is considered live: any subsequent call to klp_shadow_get may then return the shadow variable’s data pointer. So the moment it’s attached, people can start seeing it — plan accordingly. ✨

Callers of klp_shadow_*alloc should prepare shadow data accordingly. Like, get your data ready before it goes live, bestie. 🎀

The klp_shadow_*alloc API calls may allocate memory for new shadow variable structures. Their implementation does not call kmalloc inside any spinlocks, but API callers should pass GFP flags according to their specific needs. So no sneaky kmalloc in spinlocks from the implementation, but your GFP flags still need to match what you’re actually doing. 💅

The klp_shadow_hash is an RCU-enabled hashtable and is safe against concurrent klp_shadow_free and klp_shadow_get operations. Slay. 🦋

✨ SEE ALSO ✨

• Kernel file ./kernel/livepatch/shadow.c struct klp_shadow(9), klp_shadow_match(9), klp_shadow_get(9), klp_shadow_alloc(9), klp_shadow_get_or_alloc(9), klp_shadow_free(9), klp_shadow_free_all(9)

And that’s the whole page, bestie! This iconic little note comes from the manual page source/version ./kernel/livepatch, dated October 2026. Periodt. 💜