__begin_curr...crit_section(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… __begin_curr...crit_section(9) β€” from the Kernel API Manual, bestie

okay so real talk, the page title up top is __begin_curr...crit_section(9) and this whole thing lives in the Kernel API Manual, section 9. Buckle up, it's AppArmor o'clock πŸŽ€


✨ NAME ✨

__begin_current_label_crit_section β€” literally just current's confining label, that's the whole gig 🫢


🌸 SYNOPSIS 🌸

struct aa_label * __begin_current_label_crit_section (bool *needput );

πŸ¦‹ ARGUMENTS πŸ¦‹

  • needput β€” you pass in a pointer to a bool and it gets stuffed with whether the label needs to be put once you're done with the crit section. it's giving "receipt for later" energy 🧾✨

πŸ‘‘ RETURN πŸ‘‘

you get back the up-to-date confining label, or the ns unconfined label. and it's NOT NULL β€” never null, not once, so no you don't need a if (!label) check, bestie, it's fr fr guaranteed πŸ’…


πŸ”₯ DESCRIPTION πŸ”₯

it is safe to call inside locks. iconic behavior honestly, no cap πŸ™ˆ

the reference you get handed back must be put with __end_current_label_crit_section. like, that's not a suggestion, that's the contract. you take the label, you give the label back. balance. 🌈

ok so this is the part where i need you to pay attention: this must NOT be used if the task cred could be updated within the critical section β€” you know, in that window between __begin_current_label_crit_section .. __end_current_label_crit_section. don't do it. i'm serious. πŸ’€

⭐ SEE ALSO ⭐

a whole little friend group of crit-section functions, obsessed 🫢🌸


and that's the page!! it lives over in ./security/apparmor/include, dated October 2026, and the footer names it __begin_curr...crit_section(9) β€” yes the footer abbreviates it with a ..., no i don't know why either, slay πŸ’…βœ¨ πŸŽ€

πŸ“¦ where this page comes from