This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 1/2] nptl: Remove __ASSUME_SET_ROBUST_LIST
On 19/04/2017 02:36, Florian Weimer wrote:
> On 04/18/2017 11:13 PM, Adhemerval Zanella wrote:
>> This patch removes the __ASSUME_SET_ROBUST_LIST usage on nptl generic
>> code. The set_robust_list availability is defined by '__set_robust_list_avail'
>> which is now defined regardless. Its initial value is set to -1 and
>> defined to a positive value if both __NR_set_robust_list is defined
>> and the syscall returns correctly.
>
> I think we should drop support for kernels without set_robust_list. We really need something like robust mutex support for liveness detection of the nscd mappings. Making POSIX robust mutexes conditionally supported is awkward, and the fact that some architectures may lack support for them is undocumented. Application programmers will not expect this.
>
The problem is kernel supports for some architecture depends of kernel config
and the underlying hardware revision/model.
* ARM we have:
arch/arm/include/asm/futex.h
v3.0-rc1
#if defined(CONFIG_CPU_USE_DOMAINS) && defined(CONFIG_SMP)
/* ARM doesn't provide unprivileged exclusive memory accessors */
#include <asm-generic/futex.h>
#else
And it was unconditionally define only on v3.15-rc1. It means that for some
ARMv6 configure the futex_atomic_cmpxchg_inatomic may return ENOSYS.
* Microblaze have a nasty bug that was fixed only on 3.10-rc4 (f6a12a7d0b):
microblaze: Reversed logic in futex cmpxchg
futex_atomic_cmpxchg_inatomic exchanged if the values were
unequal rather than equal. This caused incorrect behavior
of robust futexes.
* MIPS still lacks proper supports depending of the underlying hardware:
arch/mips/include/asm/futex.h
142 static inline int
143 futex_atomic_cmpxchg_inatomic(u32 *uval, u32 __user *uaddr,
144 u32 oldval, u32 newval)
145 {
146 int ret = 0;
147 u32 val;
148
149 if (!access_ok(VERIFY_WRITE, uaddr, sizeof(u32)))
150 return -EFAULT;
151
152 if (cpu_has_llsc && R10000_LLSC_WAR) {
[...]
181 } else if (cpu_has_llsc) {
182 __asm__ __volatile__(
[...]
210 } else
211 return -ENOSYS;
And kernel still have support for some architecture that lacks 'cpu_has_llsc'
(although I am not sure if glibc also have support for this kind of cpu as
well).
* sh4 lacks proper SMP support (although not sure how common it is) and it was
implemented on v4.8-rc1 (00b73d8d1b71).
* m68k Uses the default include/asm-generic/futex.h which only has support for
uniprocessors.
That's why I think best option would to simplify glibc build to avoid multiple
config depending of the underlying kernel config and query robust support at
runtime. It is indeed awkward that some kernel option lacks robust support and
we can check with hardware mantainers how often or if it desirable to support
such config/chips.