kernfs_dere..._node_locked(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… kernfs_dere..._node_locked(9) ✨

okay bestie, welcome to the Kernel API Manual πŸŽ€ β€” no cap, this one's a short one but it's important, so like, pay attention fr fr.


🌸 NAME 🌸

kernfs_deref_open_node_locked β€” grab the kernfs_open_node that matches @kn, that's literally the whole job 🫢


✨ SYNOPSIS ✨

struct kernfs_open_node * kernfs_deref_open_node_locked (struct kernfs_node *kn );

like yes, that's the whole signature, she's lowkey minimal πŸ’…


πŸ¦‹ ARGUMENTS πŸ¦‹

  • kn β€” the target kernfs_node. this is the node you're asking about, bestie, hand her over and she'll hand you the goods ✨

πŸ’– DESCRIPTION πŸ’–

okay so here's the vibe: this thing fetches and returns ->attr.open of kn β€” but only when the caller is already holding kernfs_open_file_mutex_ptr(kn). that's the whole deal, iykyk πŸ”₯

and like, why does that matter? because updates to ->attr.open happen under kernfs_open_file_mutex_ptr(kn). so when the caller guarantees that this mutex is being held, other updaters literally can't touch ->attr.open, which means β€” and this is the iconic part β€” we can safely deref ->attr.open outside an RCU read-side critical section. no RCU era needed, we're free πŸ¦‹βœ¨

⚠️ but listen: the caller needs to make sure that kernfs_open_file_mutex is held. that's not a suggestion, that's the whole contract, bestie. don't skip it πŸ’€

πŸ‘‘ RETURN πŸ‘‘

kn->attr.open β€” returned when kernfs_open_file_mutex is held. that's it. that's the return value. periodt πŸ’…


🌈 SEE ALSO 🌈


and that's the page, bestie!! πŸŽ€πŸ«Ά mwah πŸ’‹ β€” this one came straight out of ./fs/kernfs, dated October 2026, under the same title kernfs_dere..._node_locked(9). slay, go hold that mutex πŸ’œβœ¨

πŸ“¦ where this page comes from