folio_lruvec(9)

💅 folio_lruvec — the Kernel API Manual, bestie edition ✨

Okay so picture this: it's a folio_lruvec(9) moment, we're deep in the kernel, and you need the lruvec for a folio you're about to isolate or put back on an LRU. Let's get into it 🫶

---

🌸 NAME 🌸

folio_lruvec — returns the lruvec, for when you're isolating or putting an LRU folio. That's the whole gig 💖

---

✨ SYNOPSIS ✨

struct lruvec * folio_lruvec (struct folio *folio );

---

🎀 ARGUMENTS 🎀

• folio — Pointer to the folio. That's it. That's the argument. King behavior honestly 👑

---

🦋 DESCRIPTION 🦋

So here's the vibe check. You call this with rcu_read_lock held, because that's what keeps the returned lruvec alive for as long as you're using it. No lock, no lifetime guarantee — that's the deal 🤝

But bestie, listen to me: holding rcu_read_lock alone will NOT guarantee the stability of the folio->lruvec association. If this races with cgroup deletion, the folio can get reparented to an ancestor. So like… the pointer's alive, but it might not be pointing at your lruvec anymore. Messy 😭

Want both the lifetime and the stability of the binding? Use folio_lruvec_lock. Once a lruvec is locked, you can call folio_lruvec on other folios too, and their binding is stable — as long as the returned lruvec matches the one you've already got locked. Lowkey iconic for lock batching, fr fr 🔥

---

🔍 SEE ALSO 🔍

Kernel file ./include/linux/memcontrol.h:

• mem_cgroup_shrink_is_root(9)
• mem_cgroup_charge(9)
• mem_cgroup_uncharge(9)
• mem_cgroup_lruvec(9)
• parent_mem_cgroup(9)

---

That's the whole page, bestie — go forth and lock responsibly 🧚💜

Sign-off szn: this little gem lives in ./include/linux, and it's dated October 2026 🌈⭐