Sources Bugzilla – Bug 9894
Support for PI futexes wrongly marked as introduced in 2.6.18
Last modified: 2013-05-10 18:50:13 UTC
While support for PI futexes has been added in 2.6.18, it depends on futex_atomic_cmpxchg_inatomic() being implemented, which has been implemented later (or not yet implemented) on some architectures. Below is the kernel version where the support has been added for main and ports glibc architectures; - i386: 2.6.18 - ia64: 2.6.19 - powerpc: 2.6.18 - s390: 2.6.18 - sparc: not implemented - sparc64: 2.6.18 - sh: 2.6.23 - x86_64: 2.6.18 - alpha: not implemented - arm: 2.6.28 - cris: not implemented - hppa : 2.6.19 - m68k: not implemented - mips: 2.6.18 Patches to fix the problem are following soon
Created attachment 3764 [details] patch for main architecture
Created attachment 3765 [details] patch for arm
Created attachment 3766 [details] patch for mips
Created attachment 3767 [details] patch for hppa
The same problem also exists with robust mutexes and is due to the same problem, ie they are available when both get/set_robust_list syscalls have been added *and* futex_atomic_cmpxchg_inatomic() is available. This give the following availabilities for main and ports glibc architectures: - i386: 2.6.17 - ia64: 2.6.19 - powerpc: 2.6.17 - s390: 2.6.18 - sparc: not implemented - sparc64: 2.6.19 - sh: 2.6.23 - x86_64: 2.6.17 - alpha: not implemented - arm: 2.6.28 - cris: not implemented - hppa : 2.6.19 - m68k: not implemented - mips: 2.6.19 Update patches fixing the problem will follow.
Created attachment 3777 [details] Updated patch for main architectures
Created attachment 3778 [details] Updated patch for arm
Created attachment 3779 [details] Updated patch for hppa
Created attachment 3780 [details] Updated patch for mips
The ARM and MIPS changes look OK; I haven't applied them because they depend on the libc changes. It might be useful to do a version of the ports changes that works with present libc (so conditionally #undefing the macros after including the libc kernel-features.h), which could be reverted and replaced with the present patch versions after the libc changes go in.
I fully agree that we can do a ports specific patch until the other patch is applied to libc. However it would be a lot easier to apply the libc patch first. What is the problem with the current libc patch? It is not specific to ports as it also concerns two main architectures from libc, that is sparc and sh.
Could you update the patches for current sources (taking account of ia64 no longer being included) and for any implementations for additional architectures in the mean time? (Patches for any additional ports architectures are optional, but the libc patch needs updating.)
Aurelien, ping regarding updating the patches for current sources and kernels. You mentioned that you were trying to review kernel-features.h generally - but incremental patches that actually exist, updating things only for some macros or some architectures, are better than ideal complete patches that don't exist - try to send small pieces to libc-alpha (CC libc-ports where ports kernel-features.h headers are updated as well) each of which fixes some particular problem without making things worse in any case.
Aurelien, could you finish these patches, please?