radix_tree_next_slot(9)

✨ radix_tree_next_slot ✨

Okay so bestie, this is a function from the Kernel API Manual and it's literally all about finding the next slot in a chunk. No cap, it's giving "where's the next one, bestie?" energy and we're gonna get into it. 💅

---

🌸 NAME 🌸

radix_tree_next_slot — find next slot in chunk

Like, it finds the next slot. In a chunk. That's the whole vibe. 🎀

---

🦋 SYNOPSIS 🦋

void __rcu ** radix_tree_next_slot (void __rcu **slot , struct
radix_tree_iter *iter , unsigned flags );

Look at that signature, it's literally iconic. Three arguments, one return, and a whole lot of radix-tree realness. ✨

---

💖 ARGUMENTS 💖

• slot — pointer to current slot. Bestie, this is where you're at right now. Your current location in the chunk. 📍
• iter — pointer to iterator state. This is the main character holding all the context so we know where we've been and where we're going. 👑
• flags — RADIX_TREE_ITER_*, should be constant. Okay so lowkey important: these flags should be constant. We don't be changing them mid-flight, periodt. 🚩

---

🔥 RETURN 🔥

Pointer to next slot, or NULL if there no more left.

That's it. That's the whole return. If you get a pointer back, slay, keep going. If you get NULL, bestie, you've hit the end and it's time to wrap it up. 🫶

---

🌈 DESCRIPTION 🌈

Okay so let me tell you what this function actually does, because it's lowkey doing a lot. 👀

This function updates iter->index in the case of a successful lookup. Yes bestie, it's mutating your iterator state on the way through — that's just how it is. 💅

For tagged lookup it also eats iter->tags. Literally eats them. They're consumed, they're gone, they served their purpose and we thank them for their service. 🍓

Now here's the part where it gets a little spicy. There are several cases where slot can be passed in as NULL to this function. And no, that's not a bug — it's a whole vibe that comes from the use of radix_tree_iter_resume or radix_tree_iter_retry. 🙈

In these cases we don't end up dereferencing — and the way that works is:

• a) we are doing tagged iteration and iter->tags has been set to 0, or
• b) we are doing non-tagged iteration, and iter->index and iter->next_index have been set up so that radix_tree_chunk_size returns 1 or 0.

So yeah, NULL slot in, no dereference out. The math checks out, the vibes are immaculate, and nobody's crashing today. 🧚

Bestie do NOT pass a NULL slot unless one of those cases is true. The function is literally telling you the exact conditions, so respect the contract. 💀

---

⭐ SEE ALSO ⭐

Okay here's the whole friend group, and honestly they're all linked up and you should probably know them all:

• Kernel file ./include/linux/radix-tree.h struct radix_tree_iter(9) — the struct itself, the blueprint, the moment
• Radix-tree synchronization(9) — all about keeping things in sync
• radix_tree_deref_slot(9) — deref a slot
• radix_tree_deref_slot_protected(9) — deref a slot but protected, fancy
• radix_tree_deref_retry(9) — retry the deref
• radix_tree_exception(9) — the exception handling one
• radix_tree_iter_init(9) — get your iterator started
• radix_tree_next_chunk(9) — next chunk energy
• radix_tree_iter_lookup(9) — the lookup one
• radix_tree_iter_retry(9) — retry with the iterator
• radix_tree_iter_resume(9) — resume where you left off
• radix_tree_chunk_size(9) — how big is the chunk, bestie
• radix_tree_for_each_slot(9) — the loop macro for slots
• radix_tree_for_each_tagged(9) — the loop macro for tagged stuff

Whole squad is here, iykyk. 👑

---

That's the whole page bestie, you ate that. This was radix_tree_next_slot(9) from the Kernel API Manual, sourced from ./include/linux and dated October 2026 — and honestly? Iconic behavior from start to finish. Periodt. 💜