[committed] hppa: undef __ASSUME_SET_ROBUST_LIST

[committed] hppa: undef __ASSUME_SET_ROBUST_LIST

[John David Anglin]

[-- Attachment #1: Type: text/plain, Size: 612 bytes --]

QEMU does not support support set_robust_list. Thus, we need
to enable detection of set_robust_list system call.

Signed-off-by: John David Anglin <dave.anglin@bell.net>
---
diff --git a/sysdeps/unix/sysv/linux/hppa/kernel-features.h b/sysdeps/unix/sysv/linux/hppa/kernel-features.h
index 0cd21ef0fa..079612e4aa 100644
--- a/sysdeps/unix/sysv/linux/hppa/kernel-features.h
+++ b/sysdeps/unix/sysv/linux/hppa/kernel-features.h
@@ -30,3 +30,6 @@
 
 #undef __ASSUME_CLONE_DEFAULT
 #define __ASSUME_CLONE_BACKWARDS 1
+
+/* QEMU does not support set_robust_list.  */
+#undef __ASSUME_SET_ROBUST_LIST


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [committed] hppa: undef __ASSUME_SET_ROBUST_LIST

[Andreas Schwab]

On Sep 20 2022, John David Anglin wrote:

> QEMU does not support support set_robust_list. Thus, we need
> to enable detection of set_robust_list system call.

This is actually a generic issue.  What are the symptoms?

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: [committed] hppa: undef __ASSUME_SET_ROBUST_LIST

[Adhemerval Zanella Netto]

On 20/09/22 17:20, John David Anglin wrote:
> QEMU does not support support set_robust_list. Thus, we need
> to enable detection of set_robust_list system call.
> 
> Signed-off-by: John David Anglin <dave.anglin@bell.net>
> ---
> diff --git a/sysdeps/unix/sysv/linux/hppa/kernel-features.h b/sysdeps/unix/sysv/linux/hppa/kernel-features.h
> index 0cd21ef0fa..079612e4aa 100644
> --- a/sysdeps/unix/sysv/linux/hppa/kernel-features.h
> +++ b/sysdeps/unix/sysv/linux/hppa/kernel-features.h
> @@ -30,3 +30,6 @@
>  
>  #undef __ASSUME_CLONE_DEFAULT
>  #define __ASSUME_CLONE_BACKWARDS 1
> +
> +/* QEMU does not support set_robust_list.  */
> +#undef __ASSUME_SET_ROBUST_LIST
> 

Does it happen only for hppa? If is a generic missing feature maybe we should
undef __ASSUME_SET_ROBUST_LIST for all architectures.

Re: [committed] hppa: undef __ASSUME_SET_ROBUST_LIST

[Florian Weimer]

* Adhemerval Zanella Netto via Libc-alpha:

> On 20/09/22 17:20, John David Anglin wrote:
>> QEMU does not support support set_robust_list. Thus, we need
>> to enable detection of set_robust_list system call.
>> 
>> Signed-off-by: John David Anglin <dave.anglin@bell.net>
>> ---
>> diff --git a/sysdeps/unix/sysv/linux/hppa/kernel-features.h b/sysdeps/unix/sysv/linux/hppa/kernel-features.h
>> index 0cd21ef0fa..079612e4aa 100644
>> --- a/sysdeps/unix/sysv/linux/hppa/kernel-features.h
>> +++ b/sysdeps/unix/sysv/linux/hppa/kernel-features.h
>> @@ -30,3 +30,6 @@
>>  
>>  #undef __ASSUME_CLONE_DEFAULT
>>  #define __ASSUME_CLONE_BACKWARDS 1
>> +
>> +/* QEMU does not support set_robust_list.  */
>> +#undef __ASSUME_SET_ROBUST_LIST
>> 
>
> Does it happen only for hppa? If is a generic missing feature maybe we should
> undef __ASSUME_SET_ROBUST_LIST for all architectures.

I think it's just a 32-bit/64-bit mismatch issue.  You can't create
32-bit robust futexes from a 64-bit process because the pointer size in
the robust list differs.  For non-process-shared mutexes, qemu-user
should be able to emulate these futexes in userspace.  It already has to
intercept thread exit, and it can walk the mutex list at that time.

I don't think it makes sense to pessimize bare-metal uses simply because
there's a qemu-user limitation.

Thanks,
Florian

Re: [committed] hppa: undef __ASSUME_SET_ROBUST_LIST

[Andreas Schwab]

On Sep 21 2022, Florian Weimer via Libc-alpha wrote:

> I think it's just a 32-bit/64-bit mismatch issue.

The endianess must match too.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: [committed] hppa: undef __ASSUME_SET_ROBUST_LIST

[John David Anglin]

On 2022-09-21 3:41 a.m., Andreas Schwab wrote:
> On Sep 20 2022, John David Anglin wrote:
>
>> QEMU does not support support set_robust_list. Thus, we need
>> to enable detection of set_robust_list system call.
> This is actually a generic issue.  What are the symptoms?
This what Helge found building Debian glibc 2.23 under qemu:

    glibc is still building but here are some more failures:
    glibc-2.34/build-tree/hppa-libc/nptl/tst-align-clone.test-result:FAIL: nptl/tst-align-clone
    glibc-2.34/build-tree/hppa-libc/nptl/tst-cancel24-static.test-result:FAIL: nptl/tst-cancel24-static
    glibc-2.34/build-tree/hppa-libc/nptl/tst-cancel24.test-result:FAIL: nptl/tst-cancel24
    glibc-2.34/build-tree/hppa-libc/nptl/tst-cancelx17.test-result:FAIL: nptl/tst-cancelx17
    glibc-2.34/build-tree/hppa-libc/nptl/tst-cleanupx4.test-result:XFAIL: nptl/tst-cleanupx4
    glibc-2.34/build-tree/hppa-libc/nptl/tst-execstack.test-result:FAIL: nptl/tst-execstack
    glibc-2.34/build-tree/hppa-libc/nptl/tst-getpid1.test-result:FAIL: nptl/tst-getpid1
    glibc-2.34/build-tree/hppa-libc/nptl/tst-mutexpi10.test-result:FAIL: nptl/tst-mutexpi10
    glibc-2.34/build-tree/hppa-libc/nptl/tst-pthread-attr-affinity-fail.test-result:FAIL: nptl/tst-pthread-attr-affinity-fail
    glibc-2.34/build-tree/hppa-libc/nptl/tst-pthread-gdb-attach-static.test-result:FAIL: nptl/tst-pthread-gdb-attach-static
    glibc-2.34/build-tree/hppa-libc/nptl/tst-pthread-gdb-attach.test-result:FAIL: nptl/tst-pthread-gdb-attach
    glibc-2.34/build-tree/hppa-libc/nptl/tst-pthread-timedlock-lockloop.test-result:FAIL: nptl/tst-pthread-timedlock-lockloop
    glibc-2.34/build-tree/hppa-libc/nptl/tst-robust-fork.test-result:FAIL: nptl/tst-robust-fork

    tst-cancel24 triggered my interest, so I checked what's doing:
    #>  QEMU_LOG=strace ./glibc-2.34/build-tree/hppa-libc/nptl/tst-cancel24
    ...
    2080424 set_robust_list(-105721680,12,0,-105720464,-100671382,1) = -1 errno=251 (Function not implemented)
    ...
    This syscall isn't implemented in qemu, and probably won't either.
    Here is the comment from qemu sources:
         case TARGET_NR_set_robust_list:
         case TARGET_NR_get_robust_list:
             /* The ABI for supporting robust futexes has userspace pass
              * the kernel a pointer to a linked list which is updated by
              * userspace after the syscall; the list is walked by the kernel
              * when the thread exits. Since the linked list in QEMU guest
              * memory isn't a valid linked list for the host and we have
              * no way to reliably intercept the thread-death event, we can't
              * support these. Silently return ENOSYS so that guest userspace
              * falls back to a non-robust futex implementation (which should
              * be OK except in the corner case of the guest crashing while
              * holding a mutex that is shared with another process via
              * shared memory).
              */
             return -TARGET_ENOSYS;

    This basically means we never will be able to succeed this test
    when building glibc on qemu-linux-user - unless we disable such tests,
    which I think isn't a good idea.


Dave

-- 
John David Anglin  dave.anglin@bell.net

Re: [committed] hppa: undef __ASSUME_SET_ROBUST_LIST

[Adhemerval Zanella Netto]

On 21/09/22 09:49, Florian Weimer wrote:
> * Adhemerval Zanella Netto via Libc-alpha:
> 
>> On 20/09/22 17:20, John David Anglin wrote:
>>> QEMU does not support support set_robust_list. Thus, we need
>>> to enable detection of set_robust_list system call.
>>>
>>> Signed-off-by: John David Anglin <dave.anglin@bell.net>
>>> ---
>>> diff --git a/sysdeps/unix/sysv/linux/hppa/kernel-features.h b/sysdeps/unix/sysv/linux/hppa/kernel-features.h
>>> index 0cd21ef0fa..079612e4aa 100644
>>> --- a/sysdeps/unix/sysv/linux/hppa/kernel-features.h
>>> +++ b/sysdeps/unix/sysv/linux/hppa/kernel-features.h
>>> @@ -30,3 +30,6 @@
>>>  
>>>  #undef __ASSUME_CLONE_DEFAULT
>>>  #define __ASSUME_CLONE_BACKWARDS 1
>>> +
>>> +/* QEMU does not support set_robust_list.  */
>>> +#undef __ASSUME_SET_ROBUST_LIST
>>>
>>
>> Does it happen only for hppa? If is a generic missing feature maybe we should
>> undef __ASSUME_SET_ROBUST_LIST for all architectures.
> 
> I think it's just a 32-bit/64-bit mismatch issue.  You can't create
> 32-bit robust futexes from a 64-bit process because the pointer size in
> the robust list differs.  For non-process-shared mutexes, qemu-user
> should be able to emulate these futexes in userspace.  It already has to
> intercept thread exit, and it can walk the mutex list at that time.
> 
> I don't think it makes sense to pessimize bare-metal uses simply because
> there's a qemu-user limitation.

Should we revert the hppa fix then? 

Re: [committed] hppa: undef __ASSUME_SET_ROBUST_LIST

[Andreas Schwab]

On Sep 21 2022, John David Anglin wrote:

>    tst-cancel24 triggered my interest, so I checked what's doing:
>    #>  QEMU_LOG=strace ./glibc-2.34/build-tree/hppa-libc/nptl/tst-cancel24
>    ...
>    2080424 set_robust_list(-105721680,12,0,-105720464,-100671382,1) = -1 errno=251 (Function not implemented)

This test doesn't fail for me for riscv64 with qemu.  Others on your
list also do not fail here.

>    This basically means we never will be able to succeed this test
>    when building glibc on qemu-linux-user - unless we disable such tests,
>    which I think isn't a good idea.

We could try to detect the situation and mark them as unsupported.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: [committed] hppa: undef __ASSUME_SET_ROBUST_LIST

[John David Anglin]

On 2022-09-21 10:05 a.m., Andreas Schwab wrote:
> On Sep 21 2022, John David Anglin wrote:
>
>>     tst-cancel24 triggered my interest, so I checked what's doing:
>>     #>  QEMU_LOG=strace ./glibc-2.34/build-tree/hppa-libc/nptl/tst-cancel24
>>     ...
>>     2080424 set_robust_list(-105721680,12,0,-105720464,-100671382,1) = -1 errno=251 (Function not implemented)
> This test doesn't fail for me for riscv64 with qemu.  Others on your
> list also do not fail here.
It depends on the kernel version reported by qemu on riscv:

/* No support for PI mutexes or robust futexes before 4.20.  */
#if __LINUX_KERNEL_VERSION < 0x041400
# undef __ASSUME_SET_ROBUST_LIST
#endif

-- 
John David Anglin  dave.anglin@bell.net

Re: [committed] hppa: undef __ASSUME_SET_ROBUST_LIST

[Andreas Schwab]

On Sep 21 2022, John David Anglin wrote:

> On 2022-09-21 10:05 a.m., Andreas Schwab wrote:
>> On Sep 21 2022, John David Anglin wrote:
>>
>>>     tst-cancel24 triggered my interest, so I checked what's doing:
>>>     #>  QEMU_LOG=strace ./glibc-2.34/build-tree/hppa-libc/nptl/tst-cancel24
>>>     ...
>>>     2080424 set_robust_list(-105721680,12,0,-105720464,-100671382,1) = -1 errno=251 (Function not implemented)
>> This test doesn't fail for me for riscv64 with qemu.  Others on your
>> list also do not fail here.
> It depends on the kernel version reported by qemu on riscv:
>
> /* No support for PI mutexes or robust futexes before 4.20.  */
> #if __LINUX_KERNEL_VERSION < 0x041400
> # undef __ASSUME_SET_ROBUST_LIST
> #endif

Ah yes, it's compiled with --enable-kernel=4.15.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: [committed] hppa: undef __ASSUME_SET_ROBUST_LIST

[Florian Weimer]

* Adhemerval Zanella Netto:

> On 21/09/22 09:49, Florian Weimer wrote:
>> * Adhemerval Zanella Netto via Libc-alpha:
>> 
>>> On 20/09/22 17:20, John David Anglin wrote:
>>>> QEMU does not support support set_robust_list. Thus, we need
>>>> to enable detection of set_robust_list system call.
>>>>
>>>> Signed-off-by: John David Anglin <dave.anglin@bell.net>
>>>> ---
>>>> diff --git a/sysdeps/unix/sysv/linux/hppa/kernel-features.h b/sysdeps/unix/sysv/linux/hppa/kernel-features.h
>>>> index 0cd21ef0fa..079612e4aa 100644
>>>> --- a/sysdeps/unix/sysv/linux/hppa/kernel-features.h
>>>> +++ b/sysdeps/unix/sysv/linux/hppa/kernel-features.h
>>>> @@ -30,3 +30,6 @@
>>>>  
>>>>  #undef __ASSUME_CLONE_DEFAULT
>>>>  #define __ASSUME_CLONE_BACKWARDS 1
>>>> +
>>>> +/* QEMU does not support set_robust_list.  */
>>>> +#undef __ASSUME_SET_ROBUST_LIST
>>>>
>>>
>>> Does it happen only for hppa? If is a generic missing feature maybe we should
>>> undef __ASSUME_SET_ROBUST_LIST for all architectures.
>> 
>> I think it's just a 32-bit/64-bit mismatch issue.  You can't create
>> 32-bit robust futexes from a 64-bit process because the pointer size in
>> the robust list differs.  For non-process-shared mutexes, qemu-user
>> should be able to emulate these futexes in userspace.  It already has to
>> intercept thread exit, and it can walk the mutex list at that time.
>> 
>> I don't think it makes sense to pessimize bare-metal uses simply because
>> there's a qemu-user limitation.
>
> Should we revert the hppa fix then? 

Probably?  It seems to be an emulation-only problem.

Thanks,
Florian