Re: [committed] hppa: undef __ASSUME_SET_ROBUST_LIST

[Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>]

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?