css_next_child(9)

📦 version 7.3.1, in nixpkgs unstable

💅 css_next_child(9) — Kernel API Manual 💅

okay bestie, welcome to the css_next_child glow-up ✨ this is a <section 9> kernel API page, and yes it's a whole vibe.

✨ NAME ✨

css_next_child — find the next child of a given css 🎀

🌸 SYNOPSIS 🌸

struct cgroup_subsys_state * css_next_child (struct cgroup_subsys_state
*pos , struct cgroup_subsys_state *parent );

🦋 ARGUMENTS 🦋

  • pos — the current position, like where you're at right now in the scroll 💅 pass NULL to initiate traversal (i.e. start from the top, main-character style)
  • parent — the css whose children we're walking through, the momager of this whole situation 👑

⭐ DESCRIPTION ⭐

So this function returns the next child of parent, and it should be called under either cgroup_mutex or an RCU read lock 🔒 that's the rule, no cap. The only requirement is that parent and pos are accessible. And the next sibling is guaranteed to be returned regardless of their states — icon behaviour, honestly 🫶

If a subsystem synchronizes ->css_online and the start of iteration, then a css which finished ->css_online is guaranteed to be visible in the future iterations, and it will stay visible until the last reference is put. periodt ✨

🙈 but heads up: a css which hasn't finished ->css_online or has already finished ->css_offline may show up during traversal. that's just how it is. it's each subsystem's responsibility to synchronize against on/offlining — so like, do your own vibe check, bestie 💀

🔥 SEE ALSO 🔥

Kernel file ./kernel/cgroup/cgroup.c — plus the whole extended friend group, because this function literally knows everyone 🫶

💖 that's the whole page, bestie, you ate 💖

shoutout to the source dir ./kernel/cgroup and the date October 2026 — this page is timestamped and looking flawless 🌈✨💜

📦 where this page comes from