ipc_addid(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… ipc_addid(9) β€” the Kernel API Manual glow-up

okay so bestie, welcome to ipc_addid from the Kernel API Manual β€” this is the little kernel function that's literally handing out IPC identifiers like they're friendship bracelets. it's short, it's sweet, and it has opinions about locking. let's get into it πŸŽ€


✨ SYNOPSIS ✨

int ipc_addid (struct ipc_ids *ids , struct kern_ipc_perm *new , int
limit );

that's it, that's the whole vibe check. she takes three things and returns an int. no cap. πŸ¦‹


🌸 ARGUMENTS 🌸

  • ids β€” the ipc identifier set, aka the group chat where all the ids live
  • new β€” the new ipc permission set, aka the new member being added to said group chat
  • limit β€” the cap on how many used ids are allowed, because even group chats have a member limit, periodt

πŸ’– DESCRIPTION πŸ’–

so what she actually does: you add an entry new to the ipc ids idr. the permissions object gets initialised, the first free entry is set up, and the index that got assigned is returned to you. congrats, that's your new id, slay πŸŽ‰

on success the new entry comes back in a locked state β€” she is holding the lock, it's her main character era, do not disturb πŸ’…

on failure tho? the entry is not locked, and you get a negative err-code back. read that again. if it fails, the caller must use ipc_rcu_putref to free the identifier. like, that's on you, bestie β€” don't leave that reference just floating around πŸ™ˆ

⚠️ big one: this function is called with the writer ipc_ids.rwsem held. that's not a vibe suggestion, that's a requirement. hold the writer lock or the whole thing is giving undefined-behaviour energy πŸ’€

πŸ‘‘ SEE ALSO πŸ‘‘

the whole friend group, all in the kernel file ./ipc/util.c:


and that's the whole page, bestie 🫢 source is ./ipc, dated October 2026, and it's the ipc_addid(9) page β€” go forth and add your ids responsibly, and remember: writer ipc_ids.rwsem held, always. mwah πŸ’‹πŸŒˆ

πŸ“¦ where this page comes from