futex_lock_pi_atomic(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… futex_lock_pi_atomic(9)

okay so bestie, we're diving into the Kernel API Manual today and the star of the show is futex_lock_pi_atomic β€” the atomic work required to acquire a pi aware futex. yes it's as serious as it sounds and yes you're gonna slay it 🫢


✨ NAME ✨

futex_lock_pi_atomic β€” Atomic work required to acquire a pi aware futex


🌸 SYNOPSIS 🌸

int futex_lock_pi_atomic (u32 __user *uaddr , struct futex_hash_bucket
*hb , union futex_key *key , struct futex_pi_state **ps , struct
task_struct *task , struct task_struct **exiting , int set_waiters );

πŸŽ€ ARGUMENTS πŸŽ€

  • uaddr β€” the pi futex user address πŸ’–
  • hb β€” the pi futex hash bucket
  • key β€” the futex key associated with uaddr and hb
  • ps β€” the pi_state pointer where we store the result of the lookup
  • task β€” the task to perform the atomic lock work for. this will be "current" except in the case of requeue pi. iykyk 😌
  • exiting β€” Pointer to store the task pointer of the owner task which is in the middle of exiting
  • set_waiters β€” force setting the FUTEX_WAITERS bit (1) or not (0)

πŸ”₯ RETURN πŸ”₯

  • 0 β€” ready to wait;
  • 1 β€” acquired the lock;
  • <0 β€” error

πŸ¦‹ DESCRIPTION πŸ¦‹

The hb->lock must be held by the caller. no cap, that's on you, not on the function πŸ’…

exiting is only set when the return value is -EBUSY. If so, this holds a refcount on the exiting task on return and the caller needs to drop it after waiting for the exit to complete.

fr fr bestie, don't forget to drop that refcount after the exit finishes β€” the vibes will NOT be immaculate otherwise 😭

πŸ‘‘ SEE ALSO πŸ‘‘


okay that's the whole page, you ate that πŸ“βœ¨ this iconic lil doc came from ./kernel/futex, dated October 2026, and it's the futex_lock_pi_atomic(9) Kernel API Manual entry β€” go forth and lock those pi aware futexes, main character πŸ’œπŸ¦‹

πŸ“¦ where this page comes from