From: Helge Deller <deller@gmx.de>

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 <deller@gmx.de>
---
 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;
     case FUTEX_WAIT_REQUEUE_PI:
@@ -8116,8 +8119,11 @@ static int do_futex(CPUState *cpu, bool time64, target_ulong uaddr,
     case FUTEX_LOCK_PI:
     case FUTEX_LOCK_PI2:
         break;
-    case FUTEX_WAKE:
     case FUTEX_WAKE_BITSET:
+        val3 = tswap32(val3);
+        timeout = 0;
+        break;
+    case FUTEX_WAKE:
     case FUTEX_TRYLOCK_PI:
     case FUTEX_UNLOCK_PI:
         timeout = 0;
-- 
2.52.0

On Fri, 23 Jan 2026 at 15:11, <deller@kernel.org> wrote:
>
> From: Helge Deller <deller@gmx.de>
>
> 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 <deller@gmx.de>
> ---
>  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.

thanks
-- PMM

On 1/23/26 16:56, Peter Maydell wrote:
> On Fri, 23 Jan 2026 at 15:11, <deller@kernel.org> wrote:
>>
>> From: Helge Deller <deller@gmx.de>
>>
>> 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 <deller@gmx.de>
>> ---
>>   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