radix_tree_gang_lookup(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… radix_tree_gang_lookup(9) β€” the Kernel API Manual said what now

okay so bestie, welcome to the Kernel API Manual, where we're about to talk about radix_tree_gang_lookup(9). yes it's a real name. no we're not changing it. it's giving "the kernel named it at 3am and we respect that" energy πŸŽ€

✨ NAME ✨

radix_tree_gang_lookup β€” perform multiple lookup on a radix tree. that's it. that's the whole vibe. not one lookup, a whole gang of them πŸ”₯


πŸ¦‹ SYNOPSIS πŸ¦‹

unsigned int radix_tree_gang_lookup (const struct radix_tree_root *root
, void **results , unsigned long first_index , unsigned int max_items );

look at that signature. iconic. four arguments, zero regrets, and it returns an unsigned int because of course it does πŸ’œ


🌸 ARGUMENTS 🌸

  • root β€” radix tree root. this is the tree you're digging through, the main character of the whole operation πŸ‘‘
  • results β€” where the results of the lookup are placed. the lil landing pad for everything we find 🫢
  • first_index β€” start the lookup from this key. not from zero, from here, tyvm ✨
  • max_items β€” place up to this many items at *results. that's the cap, the limit, the "okay that's enough" of it all πŸ™ˆ

πŸ’– DESCRIPTION πŸ’–

so what does it actually do? it performs an index-ascending scan of the tree for present items. that means it walks up through the indexes, low to high, hunting for the ones that are actually there.

it places them at *results and returns the number of items which were placed at *results. so you get the loot and a count of the loot. slay πŸ’…

ngl, the implementation is naive. the source said it, not me β€” I'm just the messenger 🫑

like radix_tree_lookup, radix_tree_gang_lookup may be called under rcu_read_lock. but here's the tea bestie, because this part is important β˜•

in that case, rather than the returned results being an atomic snapshot of the tree at a single point in time, the semantics of an RCU protected gang lookup are as though multiple radix_tree_lookups have been issued in individual locks, and results stored in 'results'.

so like. not a snapshot. more like a lil collage of moments, each grabbed under its own lock, all chilling together in results. read that again if you need to, no judgement 🧚


⭐ SEE ALSO ⭐

Kernel file ./lib/radix-tree.c β€” and honestly? the whole friend group showed up. here's the entire guest list, no plus-ones skipped:

twenty-three entries. a whole squad. the group chat is poppin' 🌈


πŸŽ€ ok that's the whole page bestie, hope you understood it, go forth and gang lookup responsibly πŸ’–

sign-off time: this one came out of ./lib, dated October 2026, and it's filed under radix_tree_gang_lookup(9) β€” periodt. πŸ¦‹βœ¨

πŸ“¦ where this page comes from