On 1/23/26 16:56, Peter Maydell wrote:
On Fri, 23 Jan 2026 at 15:11, <[email protected]> wrote:
From: Helge Deller <[email protected]>
The FUTEX_WAIT_BITSET and FUTEX_WAKE_BITSET operations use a val3
parameter for comparism. Even if this 32-bit parameter is in most cases
0xffffffff, ensure that we do a required endianess swapping if host and
guest endianess differ.
Signed-off-by: Helge Deller <[email protected]>
---
linux-user/syscall.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index c0a9a86529..7cb9de97e9 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -8106,7 +8106,10 @@ static int do_futex(CPUState *cpu, bool time64,
target_ulong uaddr,
#endif
switch (base_op) {
case FUTEX_WAIT:
+ val = tswap32(val);
+ break;
case FUTEX_WAIT_BITSET:
+ val3 = tswap32(val3);
val = tswap32(val);
break;
I see why we need to swap the "val" for these operations:
it is the value that the host kernel will be comparing
against the in-memory value. It's currently in host
order but it will be in memory in guest order, so we
must swap it.
But why do we need to swap the bitmask in val3 ? That
is in host order now and I would have thought the
host kernel also wants it in host order.
Seems it was a brain-I/O error on my side.
I'll drop that patch.
Thanks!
Helge
