From: Mathieu Desnoyers Date: Wed, 22 Jun 2022 20:49:11 +0000 (-0400) Subject: Fix: urcu-qsbr: futex wait: handle spurious futex wakeups X-Git-Tag: v0.14.0~26 X-Git-Url: https://git.liburcu.org/?a=commitdiff_plain;h=4974ad5f21d2cb17d313504f8d1252738526d588;hp=4974ad5f21d2cb17d313504f8d1252738526d588;p=urcu.git Fix: urcu-qsbr: futex wait: handle spurious futex wakeups Observed issue ============== The urcu-qsbr wait_gp() implements a futex wait/wakeup scheme identical to the workqueue code, which has an issue with spurious wakeups. A spurious wakeup on wait_gp can cause wait_gp to return with a urcu_qsbr_gp.futex state of -1, which is unexpected. It would cause the following loops in wait_for_readers() to decrement the urcu_qsbr_gp.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 the input_readers list is found to be empty. The state is restored to 0 when the input_readers list is found to be empty, which restores the futex state to a correct state for the following calls to wait_for_readers(). 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: I87f7cd3b02820cefe850c3bdb8da27fb2f9be9b2 ---