diff mbox

Correct robust mutex / PI futex kernel assumptions (bug 9894)

Message ID Pine.LNX.4.64.1403242138500.1129@digraph.polyomino.org.uk
State New
Headers show

Commit Message

Joseph Myers March 24, 2014, 9:42 p.m. UTC 
This patch continues fixing __ASSUME_* issues in preparation for
moving to a 2.6.32 minimum kernel version by addressing assumptions on
robust mutex and PI futex support availability.  Those assumptions are
bug 9894, but to be clear this patch does not address all the issues
from that bug about wrong version assumptions, only those still
applicable for --enable-kernel=2.6.32 or later (with the expectation
that the move to that minimum kernel will obsolete the other parts of
the bug).  The patch is independent of
<https://sourceware.org/ml/libc-alpha/2014-03/msg00585.html>, my other
pending-review patch preparing for the kernel version change; the two
together complete all the changes I believe are needed in preparation
regarding any macro in sysdeps/unix/sysv/linux/kernel-features.h that
would be affected by such a change.  (I have not checked the
correctness of macros whose conditions are unaffected by such a
change, or macros only defined in other kernel-features.h files.)

As discussed in that bug, robust mutexes and PI futexes need
futex_atomic_cmpxchg_inatomic to be implemented, in addition to
certain syscalls needed for robust mutexes (and
architecture-independent kernel pieces for all the features in
question).  That is, as I understand it, they need
futex_atomic_cmpxchg_inatomic to *work* (not return an ENOSYS error).

The issues identified in my analysis relate to ARM, M68K, MicroBlaze,
MIPS and SPARC.

On ARM, whether futex_atomic_cmpxchg_inatomic works depends on the
kernel configuration.  As of 3.13, the condition for *not* working is
CONFIG_CPU_USE_DOMAINS && CONFIG_SMP.  As of 2.6.32 it was simply
CONFIG_SMP that meant the feature was not implemented.  I don't know
if there are any circumstances in which we can say "we can assume a
userspace glibc binary built with these options will never run on a
kernel with the problematic configuration", but at least for now I'm
just undefining the relevant __ASSUME_* macros for ARM.

On M68K, two of the three macros are undefined for kernels before
3.10, but as far as I can see __ASSUME_FUTEX_LOCK_PI is in the same
group needing futex_atomic_cmpxchg_inatomic support and so should be
undefined as well.

On MicroBlaze the required support was added in 2.6.33.

On MIPS, the support depends on cpu_has_llsc in the kernel - that is,
actual hardware LL/SC support (GCC and glibc for MIPS GNU/Linux rely
on the instructions being supported in some way, but it may be kernel
emulation; futex_atomic_cmpxchg_inatomic doesn't work with that
emulation).  The same condition as in GCC for indicating LL/SC support
may not be available is used for undefining the macros in glibc,
__mips == 1 || defined _MIPS_ARCH_R5900.  (Maybe we could in fact
desupport MIPS processors without the hardware support in glibc.)

On SPARC, 32-bit kernels don't support futex_atomic_cmpxchg_inatomic.
I don't know if there's a more fine-grained approach than the one
taken here, not assuming the features to be present for 32-bit
userspace since we don't know if it might run on a 32-bit kernel.

This patch is not tested beyond the sanity check of an x86_64 build.

2014-03-24  Joseph Myers  <joseph@codesourcery.com>

	[BZ #9894]
	* sysdeps/unix/sysv/linux/kernel-features.h
	[__sparc__ && !__arch64__] (__ASSUME_SET_ROBUST_LIST): Do not
	define.
	[__sparc__ && !__arch64__] (__ASSUME_FUTEX_LOCK_PI): Likewise.
	[__sparc__ && !__arch64__] (__ASSUME_REQUEUE_PI): Likewise.
	* sysdeps/unix/sysv/linux/arm/kernel-features.h
	(__ASSUME_FUTEX_LOCK_PI): Undefine.
	(__ASSUME_REQUEUE_PI): Likewise.
	(__ASSUME_SET_ROBUST_LIST): Likewise.
	* sysdeps/unix/sysv/linux/m68k/kernel-features.h
	[__LINUX_KERNEL_VERSION < 0x030a00] (__ASSUME_FUTEX_LOCK_PI):
	Undefine.
	* sysdeps/unix/sysv/linux/microblaze/kernel-features.h
	[__LINUX_KERNEL_VERSION < 0x020621] (__ASSUME_FUTEX_LOCK_PI):
	Likewise.
	[__LINUX_KERNEL_VERSION < 0x020621] (__ASSUME_REQUEUE_PI):
	Likewise.
	[__LINUX_KERNEL_VERSION < 0x020621] (__ASSUME_SET_ROBUST_LIST):
	Likewise.
	* sysdeps/unix/sysv/linux/mips/kernel-features.h
	[__mips == 1 || _MIPS_ARCH_R5900] (__ASSUME_FUTEX_LOCK_PI):
	Undefine.
	[__mips == 1 || _MIPS_ARCH_R5900] (__ASSUME_REQUEUE_PI): Likewise.
	[__mips == 1 || _MIPS_ARCH_R5900] (__ASSUME_SET_ROBUST_LIST):
	Likewise.

Comments

Andreas Schwab March 24, 2014, 9:50 p.m. UTC | #1 
"Joseph S. Myers" <joseph@codesourcery.com> writes:

> diff --git a/sysdeps/unix/sysv/linux/m68k/kernel-features.h b/sysdeps/unix/sysv/linux/m68k/kernel-features.h
> index cb8915f..bc340bd 100644
> --- a/sysdeps/unix/sysv/linux/m68k/kernel-features.h
> +++ b/sysdeps/unix/sysv/linux/m68k/kernel-features.h
> @@ -48,6 +48,7 @@
>  
>  /* No support for PI futexes or robust mutexes before 3.10 for m68k.  */
>  #if __LINUX_KERNEL_VERSION < 0x030a00
> +# undef __ASSUME_FUTEX_LOCK_PI
>  # undef __ASSUME_REQUEUE_PI
>  # undef __ASSUME_SET_ROBUST_LIST
>  #endif

This is ok, thanks.  All my testing is done on 3.10+ so this never made
any difference.

Andreas.
David Miller March 24, 2014, 10:26 p.m. UTC | #2 
From: "Joseph S. Myers" <joseph@codesourcery.com>
Date: Mon, 24 Mar 2014 21:42:08 +0000

> On SPARC, 32-bit kernels don't support futex_atomic_cmpxchg_inatomic.
> I don't know if there's a more fine-grained approach than the one
> taken here, not assuming the features to be present for 32-bit
> userspace since we don't know if it might run on a 32-bit kernel.

Just like with low level locks, if we're building for 32-bit plus
V9/V8plus, we can assume the full locking primitives are available.

This is why we have a different atomic.h header file for sparc32 and
sparc32/sparcv9
Joseph Myers March 25, 2014, 12:21 a.m. UTC | #3 
On Mon, 24 Mar 2014, David Miller wrote:

> From: "Joseph S. Myers" <joseph@codesourcery.com>
> Date: Mon, 24 Mar 2014 21:42:08 +0000
> 
> > On SPARC, 32-bit kernels don't support futex_atomic_cmpxchg_inatomic.
> > I don't know if there's a more fine-grained approach than the one
> > taken here, not assuming the features to be present for 32-bit
> > userspace since we don't know if it might run on a 32-bit kernel.
> 
> Just like with low level locks, if we're building for 32-bit plus
> V9/V8plus, we can assume the full locking primitives are available.

The kernel's asm/futex.h does

#if defined(__sparc__) && defined(__arch64__)
#include <asm/futex_64.h>
#else
#include <asm/futex_32.h>
#endif

and futex_32.h just uses the asm-generic version, which just returns 
-ENOSYS.  Are you saying that if glibc is built for 32-bit plus V9/V8plus, 
then the kernel that glibc binary runs under must have been built with 
defined(__sparc__) && defined(__arch64__) true?  If so, what is the 
relevant cpp condition in userspace for "glibc can assume a kernel with 
functional futex_atomic_cmpxchg_inatomic"?
David Miller March 25, 2014, 4:30 a.m. UTC | #4 
From: "Joseph S. Myers" <joseph@codesourcery.com>
Date: Tue, 25 Mar 2014 00:21:28 +0000

> On Mon, 24 Mar 2014, David Miller wrote:
> 
>> From: "Joseph S. Myers" <joseph@codesourcery.com>
>> Date: Mon, 24 Mar 2014 21:42:08 +0000
>> 
>> > On SPARC, 32-bit kernels don't support futex_atomic_cmpxchg_inatomic.
>> > I don't know if there's a more fine-grained approach than the one
>> > taken here, not assuming the features to be present for 32-bit
>> > userspace since we don't know if it might run on a 32-bit kernel.
>> 
>> Just like with low level locks, if we're building for 32-bit plus
>> V9/V8plus, we can assume the full locking primitives are available.
> 
> The kernel's asm/futex.h does
> 
> #if defined(__sparc__) && defined(__arch64__)
> #include <asm/futex_64.h>
> #else
> #include <asm/futex_32.h>
> #endif
> 
> and futex_32.h just uses the asm-generic version, which just returns 
> -ENOSYS.  Are you saying that if glibc is built for 32-bit plus V9/V8plus, 
> then the kernel that glibc binary runs under must have been built with 
> defined(__sparc__) && defined(__arch64__) true?  If so, what is the 
> relevant cpp condition in userspace for "glibc can assume a kernel with 
> functional futex_atomic_cmpxchg_inatomic"?

A 32-bit binary compiled for v9 can only execute on 64-bit kernels.
Joseph Myers March 25, 2014, 12:19 p.m. UTC | #5 
On Tue, 25 Mar 2014, David Miller wrote:

> > and futex_32.h just uses the asm-generic version, which just returns 
> > -ENOSYS.  Are you saying that if glibc is built for 32-bit plus V9/V8plus, 
> > then the kernel that glibc binary runs under must have been built with 
> > defined(__sparc__) && defined(__arch64__) true?  If so, what is the 
> > relevant cpp condition in userspace for "glibc can assume a kernel with 
> > functional futex_atomic_cmpxchg_inatomic"?
> 
> A 32-bit binary compiled for v9 can only execute on 64-bit kernels.

Thanks for the explanation.  What's the right preprocessor conditional for 
requiring a 64-bit kernel (to replace the "defined __arch64__" in my 
patch)?
David Miller March 25, 2014, 3:12 p.m. UTC | #6 
From: "Joseph S. Myers" <joseph@codesourcery.com>
Date: Tue, 25 Mar 2014 12:19:12 +0000

> On Tue, 25 Mar 2014, David Miller wrote:
> 
>> > and futex_32.h just uses the asm-generic version, which just returns 
>> > -ENOSYS.  Are you saying that if glibc is built for 32-bit plus V9/V8plus, 
>> > then the kernel that glibc binary runs under must have been built with 
>> > defined(__sparc__) && defined(__arch64__) true?  If so, what is the 
>> > relevant cpp condition in userspace for "glibc can assume a kernel with 
>> > functional futex_atomic_cmpxchg_inatomic"?
>> 
>> A 32-bit binary compiled for v9 can only execute on 64-bit kernels.
> 
> Thanks for the explanation.  What's the right preprocessor conditional for 
> requiring a 64-bit kernel (to replace the "defined __arch64__" in my 
> patch)?

There isn't.  You really have to base it upon the config triplet, by
placing the header file in question under a sparc32/v9 subdirectory.

You could include atomic.h and do tests on __sparc32_atomic_do_lock like
lowlevellock.h does, but that's really ugly.
Joseph Myers March 25, 2014, 3:35 p.m. UTC | #7 
On Tue, 25 Mar 2014, David Miller wrote:

> From: "Joseph S. Myers" <joseph@codesourcery.com>
> Date: Tue, 25 Mar 2014 12:19:12 +0000
> 
> > On Tue, 25 Mar 2014, David Miller wrote:
> > 
> >> > and futex_32.h just uses the asm-generic version, which just returns 
> >> > -ENOSYS.  Are you saying that if glibc is built for 32-bit plus V9/V8plus, 
> >> > then the kernel that glibc binary runs under must have been built with 
> >> > defined(__sparc__) && defined(__arch64__) true?  If so, what is the 
> >> > relevant cpp condition in userspace for "glibc can assume a kernel with 
> >> > functional futex_atomic_cmpxchg_inatomic"?
> >> 
> >> A 32-bit binary compiled for v9 can only execute on 64-bit kernels.
> > 
> > Thanks for the explanation.  What's the right preprocessor conditional for 
> > requiring a 64-bit kernel (to replace the "defined __arch64__" in my 
> > patch)?
> 
> There isn't.  You really have to base it upon the config triplet, by
> placing the header file in question under a sparc32/v9 subdirectory.

In that case, I'd like to propose the SPARC changes in the patch as-is 
(i.e. not assuming these features for 32-bit SPARC).

I *would* like all architectures to move to architecture-specific 
kernel-features.h files as used for ex-ports architectures (overriding the 
architecture-independent file as needed) - but such a move will be a lot 
simpler after the move to 2.6.32 minimum kernel version and some of the 
consequent cleanups, and that depends on this patch (and the previous 
MicroBlaze one pending review) to avoid possibly breaking things for some 
architectures.
David Miller March 25, 2014, 10:09 p.m. UTC | #8 
From: "Joseph S. Myers" <joseph@codesourcery.com>
Date: Tue, 25 Mar 2014 15:35:00 +0000

> In that case, I'd like to propose the SPARC changes in the patch as-is 
> (i.e. not assuming these features for 32-bit SPARC).

This is a very serious regression you are adding to the tree.
Joseph Myers March 25, 2014, 10:55 p.m. UTC | #9 
On Tue, 25 Mar 2014, David Miller wrote:

> From: "Joseph S. Myers" <joseph@codesourcery.com>
> Date: Tue, 25 Mar 2014 15:35:00 +0000
> 
> > In that case, I'd like to propose the SPARC changes in the patch as-is 
> > (i.e. not assuming these features for 32-bit SPARC).
> 
> This is a very serious regression you are adding to the tree.

It's a few conditional branches (that are already present in the default 
--enable-kernel=2.6.16 configuration) in order to avoid another regression 
(namely, the change to 2.6.32 default causing features to be assumed by 
default when they aren't present).  But if you'd prefer the latter, I can 
drop the SPARC parts of this patch and bug 9894 can be left open for 
32-bit SPARC after the default version changes.
David Miller March 25, 2014, 11:06 p.m. UTC | #10 
From: "Joseph S. Myers" <joseph@codesourcery.com>
Date: Tue, 25 Mar 2014 22:55:03 +0000

> On Tue, 25 Mar 2014, David Miller wrote:
> 
>> From: "Joseph S. Myers" <joseph@codesourcery.com>
>> Date: Tue, 25 Mar 2014 15:35:00 +0000
>> 
>> > In that case, I'd like to propose the SPARC changes in the patch as-is 
>> > (i.e. not assuming these features for 32-bit SPARC).
>> 
>> This is a very serious regression you are adding to the tree.
> 
> It's a few conditional branches (that are already present in the default 
> --enable-kernel=2.6.16 configuration) in order to avoid another regression 
> (namely, the change to 2.6.32 default causing features to be assumed by 
> default when they aren't present).  But if you'd prefer the latter, I can 
> drop the SPARC parts of this patch and bug 9894 can be left open for 
> 32-bit SPARC after the default version changes.

Actually, it turns out you can simply test for the CPP macro __sparc_v9__
diff mbox

Patch

diff --git a/sysdeps/unix/sysv/linux/arm/kernel-features.h b/sysdeps/unix/sysv/linux/arm/kernel-features.h
index 401343b..96b7350 100644
--- a/sysdeps/unix/sysv/linux/arm/kernel-features.h
+++ b/sysdeps/unix/sysv/linux/arm/kernel-features.h
@@ -53,3 +53,10 @@ 
 # undef __ASSUME_PSELECT
 # undef __ASSUME_PPOLL
 #endif
+
+/* The ARM kernel may or may not support
+   futex_atomic_cmpxchg_inatomic, depending on kernel
+   configuration.  */
+#undef __ASSUME_FUTEX_LOCK_PI
+#undef __ASSUME_REQUEUE_PI
+#undef __ASSUME_SET_ROBUST_LIST
diff --git a/sysdeps/unix/sysv/linux/kernel-features.h b/sysdeps/unix/sysv/linux/kernel-features.h
index 555b82c..a1853c3 100644
--- a/sysdeps/unix/sysv/linux/kernel-features.h
+++ b/sysdeps/unix/sysv/linux/kernel-features.h
@@ -106,9 +106,12 @@ 
 # define __ASSUME_ATFCTS	1
 #endif
 
-/* Support for inter-process robust mutexes was added in 2.6.17.  */
+/* Support for inter-process robust mutexes was added in 2.6.17 (but
+   some architectures lack futex_atomic_cmpxchg_inatomic in some
+   configurations).  */
 #if __LINUX_KERNEL_VERSION >= 0x020611 \
-    && (!defined __sh__ || __LINUX_KERNEL_VERSION >= 0x020613)
+    && (!defined __sh__ || __LINUX_KERNEL_VERSION >= 0x020613) \
+    && !(defined __sparc__ && !defined __arch64__)
 # define __ASSUME_SET_ROBUST_LIST	1
 #endif
 
@@ -119,8 +122,10 @@ 
 # define __ASSUME_COMPLETE_READV_WRITEV	1
 #endif
 
-/* Support for PI futexes was added in 2.6.18.  */
-#if __LINUX_KERNEL_VERSION >= 0x020612
+/* Support for PI futexes was added in 2.6.18 (but some architectures
+   lack futex_atomic_cmpxchg_inatomic in some configurations).  */
+#if __LINUX_KERNEL_VERSION >= 0x020612 \
+    && !(defined __sparc__ && !defined __arch64__)
 # define __ASSUME_FUTEX_LOCK_PI	1
 #endif
 
@@ -223,8 +228,11 @@ 
 # define __ASSUME_PWRITEV	1
 #endif
 
-/* Support for FUTEX_*_REQUEUE_PI was added in 2.6.31.  */
-#if __LINUX_KERNEL_VERSION >= 0x02061f
+/* Support for FUTEX_*_REQUEUE_PI was added in 2.6.31 (but some
+   architectures lack futex_atomic_cmpxchg_inatomic in some
+   configurations).  */
+#if __LINUX_KERNEL_VERSION >= 0x02061f \
+    && !(defined __sparc__ && !defined __arch64__)
 # define __ASSUME_REQUEUE_PI	1
 #endif
 
diff --git a/sysdeps/unix/sysv/linux/m68k/kernel-features.h b/sysdeps/unix/sysv/linux/m68k/kernel-features.h
index cb8915f..bc340bd 100644
--- a/sysdeps/unix/sysv/linux/m68k/kernel-features.h
+++ b/sysdeps/unix/sysv/linux/m68k/kernel-features.h
@@ -48,6 +48,7 @@ 
 
 /* No support for PI futexes or robust mutexes before 3.10 for m68k.  */
 #if __LINUX_KERNEL_VERSION < 0x030a00
+# undef __ASSUME_FUTEX_LOCK_PI
 # undef __ASSUME_REQUEUE_PI
 # undef __ASSUME_SET_ROBUST_LIST
 #endif
diff --git a/sysdeps/unix/sysv/linux/microblaze/kernel-features.h b/sysdeps/unix/sysv/linux/microblaze/kernel-features.h
index f9a61a9..a62b839 100644
--- a/sysdeps/unix/sysv/linux/microblaze/kernel-features.h
+++ b/sysdeps/unix/sysv/linux/microblaze/kernel-features.h
@@ -43,6 +43,13 @@ 
 
 #include_next <kernel-features.h>
 
+/* Support for futex_atomic_cmpxchg_inatomic was added in 2.6.33.  */
+#if __LINUX_KERNEL_VERSION < 0x020621
+# undef __ASSUME_FUTEX_LOCK_PI
+# undef __ASSUME_REQUEUE_PI
+# undef __ASSUME_SET_ROBUST_LIST
+#endif
+
 /* The MicroBlaze kernel does not support the pselect6, preadv and
    pwritev syscalls.  */
 #undef __ASSUME_PSELECT
diff --git a/sysdeps/unix/sysv/linux/mips/kernel-features.h b/sysdeps/unix/sysv/linux/mips/kernel-features.h
index 52cbf3a..19d3cba 100644
--- a/sysdeps/unix/sysv/linux/mips/kernel-features.h
+++ b/sysdeps/unix/sysv/linux/mips/kernel-features.h
@@ -53,3 +53,11 @@ 
 #if _MIPS_SIM == _ABIN32 && __LINUX_KERNEL_VERSION < 0x020623
 # undef __ASSUME_GETDENTS64_SYSCALL
 #endif
+
+/* The MIPS kernel does not support futex_atomic_cmpxchg_inatomic if
+   emulating LL/SC.  */
+#if __mips == 1 || defined _MIPS_ARCH_R5900
+# undef __ASSUME_FUTEX_LOCK_PI
+# undef __ASSUME_REQUEUE_PI
+# undef __ASSUME_SET_ROBUST_LIST
+#endif