latch_tree_find(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… latch_tree_find(9) β€” a Kernel API Manual moment ✨

okay so this is latch_tree_find(9) from the Kernel API Manual, and honestly? she's giving lockless-search-icon realness and we're obsessed πŸŽ€


🌸 NAME 🌸

latch_tree_find β€” literally finds the node matching @key in the trees @root, no cap 🫢


✨ SYNOPSIS ✨

struct latch_tree_node * latch_tree_find (void *key , struct
       latch_tree_root *root , const struct latch_tree_ops *ops );

yeah bestie, that's the whole signature, copy it exactly, don't be weird about the spacing πŸ’…


πŸ¦‹ ARGUMENTS πŸ¦‹

  • key β€” the search key, like, the thing you're looking for πŸ”
  • root β€” the trees to search for key, plural trees, she contains multitudes 🌈
  • ops β€” the operators defining the node order, the vibe-check-rules basically ⭐

πŸ’– DESCRIPTION πŸ’–

so what she does: does a lockless lookup in the trees root for the node matching key. lockless! no locks! main character energy, she just goes ✨

⚠️ big caveat bestie: it is assumed that this is called while holding the appropriate RCU read side lock. like, that's the whole premise. don't skip that part fr fr 😭

and here's the messy part πŸ™ˆ β€” if the operators define a partial order on the elements (meaning there are multiple elements which have the same key value), then it is undefined which of these elements will be found. undefined! not "whichever one you want", not "the first one", literally undefined πŸ’€

nor is it possible to iterate the tree to find further elements with the same key value. so like, one look, one shot, that's it, no scrolling for more 🫠


πŸŽ€ RETURN πŸŽ€

a pointer to the node matching key or NULL. that's it. she either ate or she gave you nothing πŸ‘‘


🌟 SEE ALSO 🌟


and that's the whole page, bestie πŸ§šπŸ’œ this little gem lives in ./include/linux, it's dated October 2026, and it's filed under latch_tree_find(9) β€” go forth and find your nodes responsibly πŸ’…πŸŒΈβœ¨

πŸ“¦ where this page comes from