mas_find(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… mas_find β€” a.k.a. the kernel API manual page, bestie

Okay so before we even get into it: this is from the Kernel API Manual (section 9, kernel developer land, very "I read source code for fun" of it) and honestly? It's a short one. A little sleeper hit. Let's get into it 🫢


✨ NAME ✨

mas_find β€” on the first call, find the entry at or after mas->index up to %max. Otherwise, find the entry after mas->index.

Like, that's the whole vibe. First call = inclusive-ish search from your index onward. Every call after that = "okay bestie, keep going, next one please" ✨


πŸŽ€ SYNOPSIS πŸŽ€

void * mas_find (struct ma_state *mas , unsigned long max );

That's it. That's the whole signature. Returns a void *, takes a maple state and a max. Iconic minimalism, no notes πŸ’…


🌸 ARGUMENTS 🌸

  • mas β€” the maple state 🍁 like, the whole state of your maple tree traversal. This is where everything lives and where everything gets updated.
  • max β€” the maximum value to check. Your ceiling. Your "no further than this, babe" boundary.

πŸ¦‹ DESCRIPTION πŸ¦‹

Okay so real talk, the important bit first: you must hold rcu_read_lock or the write lock. No cap, this is not optional. If you're out here calling mas_find with no lock held, that's not main character energy, that's undefined chaos energy 😭

So when you call it β€” if an entry exists, last and index get updated accordingly. So it's not just a lookup, it's also moving your state forward. Very "I do two things and I do them well" of it.

It may set mas->status to ma_overflow β€” so keep an eye on that status field, bestie, it's telling you something πŸ‘€

Reminder with love: rcu_read_lock or the write lock, or nothing. Fr fr. πŸ’€

⭐ RETURN ⭐

The entry, or NULL. That's it. Either you get your pointer or you get the void. Very binary of it, honestly πŸŽ€

(And NULL isn't a failure necessarily β€” remember, this searches. Nothing found = NULL, that's just how searching works, iykyk.)


🌈 SEE ALSO 🌈

Buckle up, this list is long and it is not skipping anybody. The kernel file is ./lib/maple_tree.c and here's the whole friend group:

mas_prealloc_calc(9), mas_wr_preallocate(9), mas_insert(9), mas_alloc_cyclic(9), mas_walk(9), mte_dead_walk(9), mt_free_walk(9), mas_store(9), mas_store_gfp(9), mas_store_prealloc(9), mas_preallocate(9), mas_next(9), mas_next_range(9), mt_next(9), mas_prev(9), mas_prev_range(9), mt_prev(9), mas_pause(9), mas_find_setup(9), mas_find_range(9), mas_find_rev_setup(9), mas_find_rev(9), mas_find_range_rev(9), mas_erase(9), mas_nomem(9), mas_nomem_nofail(9), mtree_load(9), mtree_store_range(9), mtree_store(9), mtree_insert_range(9), mtree_insert(9), mtree_alloc_cyclic(9), mtree_erase(9), __mt_dup(9), mtree_dup(9), __mt_destroy(9), mtree_destroy(9), mt_find(9), mt_find_after(9)

Thirty-nine whole references and yes I counted, we do not do "etc." here πŸ§šπŸ’–


So that's the page! Shoutout to the source file ./lib and the date October 2026 β€” the manual page literally says so, so I'm saying so, periodt. Go hold that lock, bestie πŸ’œβœ¨

πŸ“¦ where this page comes from