list_lru_lock(9)

👑 list_lru_lock 👑

okay bestie, welcome to list_lru_lock from the Kernel API Manual. this is the lock-the-right-sublist situation, and yes, it's giving main character energy. let's get into it 💅✨

🎀 NAME 🎀

list_lru_lock — lock the sublist for the given node and memcg. periodt. 🔒

🦋 SYNOPSIS 🦋

struct list_lru_one * list_lru_lock (struct list_lru *lru , int nid ,
struct mem_cgroup **memcg );

💖 ARGUMENTS 💖

• lru — the lru pointer. that's literally the pointer, bestie 🫶
• nid — the node id of the sublist to lock. slay, we love a specific sublist 🔥
• memcg — pointer to the cgroup of the sublist to lock. on return, it gets updated to the cgroup whose sublist was actually locked — and plot twist, that may be an ancestor if the original memcg was dying 😭

✨ DESCRIPTION ✨

Returns the locked list_lru_one sublist. the caller must call list_lru_unlock when done — yes, you have to give it back, no ghosting 💀

You must ensure that the memcg is not freed during this call (e.g., with rcu or by taking a css refcnt). this is the “do not let it vanish mid-lock” rule, fr fr — keep it alive with rcu or a css refcnt, or it's bad vibes 🚨

🔥 RETURN 🔥

the locked list_lru_one, or NULL on failure. that's the whole vibe: you either got the locked sublist or you got NULL, no in-between 🌈

🌸 SEE ALSO 🌸

• Kernel file ./include/linux/list_lru.h
• folio_memcg_list_lru_alloc(9)
• list_lru_unlock(9)
• list_lru_add(9)
• list_lru_add_obj(9)
• list_lru_del(9)
• list_lru_del_obj(9)
• list_lru_count_one(9)
• list_lru_walk_one(9)
• list_lru_walk_one_irq(9)

mwah 💋 — source/version is ./include/linux, date is October 2026. go lock that sublist, bestie, iykyk 👑🎀