--- name: "futex_wait_requeue_pi" section: "9" platform: "linux" package: "linux-manual-4.9" version: "4.9.228-1" release: "Debian 9 (Stretch)" platforms: ["linux"] url: "https://new.carta.tech/futex_wait_requeue_pi" --- # futex\_wait\_requeue\_pi(9) Wait on uaddr and take uaddr2 ## NAME futex\_wait\_requeue\_pi - Wait on uaddr and take uaddr2 ## SYNOPSIS **int futex\_wait\_requeue\_pi(u32 \_\_user \*** *uaddr***, unsigned int** *flags***, u32** *val***, ktime\_t \*** *abs\_time***, u32** *bitset***, u32 \_\_user \*** *uaddr2***);** ## ARGUMENTS *uaddr* the futex we initially wait on (non-pi) *flags* futex flags (FLAGS\_SHARED, FLAGS\_CLOCKRT, etc.), they must be the same type, no requeueing from private to shared, etc. *val* the expected value of uaddr *abs\_time* absolute timeout *bitset* 32 bit wakeup bitset set by userspace, defaults to all *uaddr2* the pi futex we will take prior to returning to user-space ## DESCRIPTION The caller will wait on uaddr and will be requeued by **futex\_requeue** to uaddr2 which must be PI aware and unique from uaddr. Normal wakeup will wake on uaddr2 and complete the acquisition of the rt\_mutex prior to returning to userspace. This ensures the rt\_mutex maintains an owner when it has waiters; without one, the pi logic would not know which task to boost/deboost, if there was a need to. We call schedule in **futex\_wait\_queue\_me** when we enqueue and return there via the following-- 1) wakeup on uaddr2 after an atomic lock acquisition by **futex\_requeue** 2) wakeup on uaddr2 after a requeue 3) signal 4) timeout If 3, cleanup and return -ERESTARTNOINTR. If 2, we may then block on trying to take the rt\_mutex and return via: 5) successful lock 6) signal 7) timeout 8) other lock acquisition failure If 6, return -EWOULDBLOCK (restarting the syscall would do the same). If 4 or 7, we cleanup and return with -ETIMEDOUT. ## RETURN 0 - On success; \<0 - On error ## AUTHOR **Rusty Russell** \ Author. ## COPYRIGHT