[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