On 2024/12/28 20:11, Phil Dennis-Jordan wrote:
This is somewhat orthogonal to the issue being addressed here, but:
While reading the man page to make sense of this patch, I noticed the
following:
> If the futex value does not match val, then the call fails
> immediately with the error EAGAIN.
And qemu_futex_wait does not seem to handle that case. In fact it seems
like it would take the default: abort(); code path?
It's handled as EWOULDBLOCK. The man page says:
> Note: on Linux, the symbolic names EAGAIN and EWOULDBLOCK (both of
> which appear in different parts of the kernel futex code) have the
> same value.
If I've got this right, I'm surprised there aren't spurious abort()s
happening, but I suppose QemuEvent and qemu_futex_* are used fairly
sparingly and in low-contention areas.
QemuLockCnt, which relies on qemu_futex_*, is used in more contended
areas so it will cause trouble if qemu_futex_* is broken.
