__find_child(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’– __find_child(9) β€” Kernel API Manual πŸ’–

okay so bestie, welcome to the __find_child page from the Kernel API Manual β€” this is the little gremlin function that goes digging through a list of AppArmor profiles looking for one whose name matches. she's giving "where's my bestie" energy and honestly? iconic. πŸŽ€


✨ NAME ✨

__find_child β€” find a profile on @head list with a name matching @name πŸ¦‹


✨ SYNOPSIS ✨

struct aa_profile * __find_child (struct list_head *head , const char *name );

✨ ARGUMENTS ✨

  • head β€” the list you're gonna search. NOT NULL, bestie, do not come in here with a null pointer, fr fr πŸ™ˆ
  • name β€” the name of the profile you're hunting for. also NOT NULL. no cap. πŸ’…

✨ DESCRIPTION ✨

okay so here's the vibe check: this function requires that rcu_read_lock be held. like, that's the prerequisite. it's required, not a suggestion, not a cute optional accessory β€” keep that read lock held or the whole thing is a bad time. πŸ”₯


✨ RETURN ✨

she hands you back an unrefcounted profile ptr β€” or NULL if nothing was found. that's the whole deal. if it's NULL, the profile's just not there, don't take it personally 🫢

like literally β€” an unrefcounted pointer. keep that in mind, it's not doing the refcount math for you.

✨ SEE ALSO ✨

Kernel file ./security/apparmor/policy.c β€” and the whole extended friend group, because she does not exist in a vacuum, periodt:


and that's the whole page bestie!! 🌈⭐ this one ships out of ./security/apparmor and it's dated October 2026, so go forth, hold your rcu_read_lock, find your child, and slay πŸ‘‘πŸ’œπŸ’«

πŸ“¦ where this page comes from