radix_tree_gang_lookup(9)
π 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:
radix_tree_find_next_bit(9)radix_tree_shrink(9)__radix_tree_create(9)radix_tree_insert(9)__radix_tree_lookup(9)radix_tree_lookup_slot(9)radix_tree_lookup(9)__radix_tree_replace(9)radix_tree_replace_slot(9)radix_tree_iter_replace(9)radix_tree_tag_set(9)radix_tree_tag_clear(9)radix_tree_iter_tag_clear(9)radix_tree_tag_get(9)radix_tree_next_chunk(9)radix_tree_gang_lookup_tag(9)radix_tree_gang_lookup_tag_slot(9)radix_tree_iter_delete(9)radix_tree_delete_item(9)radix_tree_delete(9)radix_tree_tagged(9)idr_preload(9)idr_destroy(9)
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
- nixpkgs unstable: linux-manual 7.3.1
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash-1017 on : a language model's rewrite of the original, under its terms