diff options
| author | Akihiko Odaki <akihiko.odaki@daynix.com> | 2025-05-29 14:45:50 +0900 |
|---|---|---|
| committer | Paolo Bonzini <pbonzini@redhat.com> | 2025-06-06 14:32:55 +0200 |
| commit | 6e2d11bf04fb18e60afc8551871d9acb7b56983d (patch) | |
| tree | 744dbbcb8debe3ef51de012bef56c1e732ab3481 /util/qemu-thread-posix.c | |
| parent | 4cdc489eb9c25f76255a550a4a0b19cda3435a76 (diff) | |
| download | focaccia-qemu-6e2d11bf04fb18e60afc8551871d9acb7b56983d.tar.gz focaccia-qemu-6e2d11bf04fb18e60afc8551871d9acb7b56983d.zip | |
futex: Check value after qemu_futex_wait()
futex(2) - Linux manual page https://man7.org/linux/man-pages/man2/futex.2.html > 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, > callers 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. Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Link: https://lore.kernel.org/r/20250529-event-v5-1-53b285203794@daynix.com Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Diffstat (limited to 'util/qemu-thread-posix.c')
| -rw-r--r-- | util/qemu-thread-posix.c | 24 |
1 files changed, 12 insertions, 12 deletions
diff --git a/util/qemu-thread-posix.c b/util/qemu-thread-posix.c index b2e26e2120..f81fca5c11 100644 --- a/util/qemu-thread-posix.c +++ b/util/qemu-thread-posix.c @@ -428,17 +428,17 @@ void qemu_event_wait(QemuEvent *ev) assert(ev->initialized); - /* - * qemu_event_wait must synchronize with qemu_event_set even if it does - * not go down the slow path, so this load-acquire is needed that - * synchronizes with the first memory barrier in qemu_event_set(). - * - * If we do go down the slow path, there is no requirement at all: we - * might miss a qemu_event_set() here but ultimately the memory barrier in - * qemu_futex_wait() will ensure the check is done correctly. - */ - value = qatomic_load_acquire(&ev->value); - if (value != EV_SET) { + while (true) { + /* + * qemu_event_wait must synchronize with qemu_event_set even if it does + * not go down the slow path, so this load-acquire is needed that + * synchronizes with the first memory barrier in qemu_event_set(). + */ + value = qatomic_load_acquire(&ev->value); + if (value == EV_SET) { + break; + } + if (value == EV_FREE) { /* * Leave the event reset and tell qemu_event_set that there are @@ -452,7 +452,7 @@ void qemu_event_wait(QemuEvent *ev) * like the load above. */ if (qatomic_cmpxchg(&ev->value, EV_FREE, EV_BUSY) == EV_SET) { - return; + break; } } |