[PATCH 2/3] nptl: Do not always assume set_robust_list availability (BZ 33225)
Daniel Henrique Barboza
dbarboza@ventanamicro.com
Tue Jul 29 22:16:38 GMT 2025
On 7/29/25 5:32 PM, Florian Weimer wrote:
> * Adhemerval Zanella:
>
>> The __ASSUME_SET_ROBUST_LIST is used to define and set
>> __nptl_set_robust_list_avail to advertise process shared robust mutex
>> support, done at __tls_init_tp (during pthread initialization).
>>
>> Some specific kernel configurations and the qemu-user (for all ABIs) do
>> not implement the set_robust_list syscal. Therefore, for the default case
>> (__ASSUME_SET_ROBUST_LIST being true), the missing support is not
>> detected, and pthread_mutex_init succeeds where it should fail. For
>> instance, the sequence succeeds on qemu-user even when set_robust_list
>> fails with ENOSYS.
>>
>> pthread_mutexattr_init(&attr);
>> pthread_mutexattr_setpshared(&attr, PTHREAD_PROCESS_SHARED);
>> pthread_mutexattr_setrobust(&attr, PTHREAD_MUTEX_ROBUST);
>>
>> pthread_mutex_init(&mutex, &attr);
>>
>> This patch removes __ASSUME_SET_ROBUST_LIST and always enables
>> __nptl_set_robust_list_avail detection.
>
> I'm not sure this is the right direction. Is qemu-user compatibility
> that important to users?
>
> Why can't support for set_robust_list be added to qemu-user? It's
> probably not easy, but if robust mutex functionality is important to
> qemu-user users, wouldn't that make more sense?
Here's the documented reason why QEMU doesn't implement this syscall:
(QEMU source linux-user/syscall.c)
#ifdef TARGET_NR_set_robust_list
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;
#endif
Maybe things got easier (this comment is 12+ years old) but the nature of this
syscall is indeed tricky to deal with.
Thanks,
Daniel
>
> Thanks,
> Florian
>
More information about the Libc-alpha
mailing list