From: Mathieu Desnoyers Date: Thu, 23 Jun 2022 19:58:04 +0000 (-0400) Subject: Fix: sessiond wait futex: handle spurious futex wakeups X-Git-Tag: v2.12.6~8 X-Git-Url: http://git.lttng.org./?a=commitdiff_plain;ds=sidebyside;h=4c308bbd7313014c58a5ed28a88b9b39939e8729;hp=4c308bbd7313014c58a5ed28a88b9b39939e8729;p=lttng-ust.git Fix: sessiond wait futex: handle spurious futex wakeups Observed issue ============== LTTng-UST scheme for letting listener threads wait on session daemon to wake up a futex is similar to the liburcu workqueue code, which has an issue with spurious wakeups. This wait/wakeup scheme is only used after the LTTng-UST listener thread has been unable to connect to the session daemon. A spurious wakeup on wait_for_sessiond can cause wait_for_sessiond to return with a sock_info->wait_shm_mmap state of 0, which is unexpected. However, this should not cause any user-observable issues other than using slightly more CPU time than strictly needed, because this spurious wakeup will only cause an additional connection attempt to the session daemon to fail. 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 0 in user-space after the call to FUTEX_WAIT returns 0. Known drawbacks =============== None. Signed-off-by: Mathieu Desnoyers Change-Id: I468d8ff302f467ee9924e6edb04476fcb031b4b9 ---