From: Mathieu Desnoyers Date: Wed, 22 Jun 2022 20:46:50 +0000 (-0400) Subject: Fix: defer_rcu: futex wait: handle spurious futex wakeups X-Git-Tag: v0.14.0~29 X-Git-Url: https://git.lttng.org/?a=commitdiff_plain;h=879a3e166178d16b2ffedc73899904d52285cfe8;hp=879a3e166178d16b2ffedc73899904d52285cfe8;p=urcu.git Fix: defer_rcu: futex wait: handle spurious futex wakeups Observed issue ============== The urcu-defer wait_defer() implements a futex wait/wakeup scheme identical to the workqueue code, which has an issue with spurious wakeups. A spurious wakeup on wait_defer can cause wait_defer to return with a defer_thread_futex state of -1, which is unexpected. It would cause the following loops in thr_defer() to decrement the defer_thread_futex to values below -1, thus actively using CPU as values will be decremented to very low negative values until it reaches 0 through underflow, or until callbacks are eventually queued. The state is restored to 0 when callbacks are found, which restores the futex state to a correct state for the following calls to wait_defer(). This issue will cause spurious unexpected high CPU use, but will not lead to data corruption. Cause ===== From futex(5): FUTEX_WAIT Returns 0 if the caller was woken up. Note that a wake-up can also be caused by common futex usage patterns in unrelated code that happened to have previously used the futex word's memory location (e.g., typical futex-based implementations of Pthreads mutexes can cause this under some conditions). Therefore, call‐ ers should always conservatively assume that a return value of 0 can mean a spurious wake-up, and use the futex word's value (i.e., the user-space synchronization scheme) to decide whether to continue to block or not. Solution ======== We therefore need to validate whether the value differs from -1 in user-space after the call to FUTEX_WAIT returns 0. Known drawbacks =============== None. Signed-off-by: Mathieu Desnoyers Change-Id: Id9c104c0bb77cc306f0b8fbf0b924bdda2aaaf4c ---