[Bug nptl/18463] pthread_cond_broadcast issue when surrounded by PTHREAD_PRIO_INHERIT mutex on ARM

[adhemerval.zanella at linaro dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=18463

--- Comment #13 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
For __ASSUME_FUTEX_LOCK_PI, which will use FUTEX_{LOCK,UNLOCK}_PI, glibc can
assume it will return -ENOSYS in all the cases since 'do_futex' will first
check if 'futex_cmpxchg_enabled' is defined by the architecture. And as far I
could check, the missing one that does not really support
futex_atomic_cmpxchg_inatomic in 3.2 (arm, m68k, mips, sparc) will either
return if it supports or use the default futex.h implementation that returns
-ENOSYS.

But we can not assume the same thing for __ASSUME_REQUEUE_PI which will use the
FUTEX_WAIT_REQUEUE_PI and FUTEX_CMP_REQUEUE_PI operation, since for linux v3.2
there is no runtime check in kernel/futex.c.  This is only done by
59263b513c11398cd66a52d4c5b2b118ce1e0359 which only appears on v3.4.

The possible cleanup I see is to remove __ASSUME_FUTEX_LOCK_PI, since kernel
will return -ENOSYS for all supported arch if futex_atomic_cmpxchg_inatomic is
not supported in the particular kernel configuration; and change the
__ASSUME_REQUEUE_PI minimum kernel for arm to enable it for v3.4+.

-- 
You are receiving this mail because:
You are on the CC list for the bug.