This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Correct robust mutex / PI futex kernel assumptions (bug 9894)
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: David Miller <davem at davemloft dot net>
- Cc: <libc-alpha at sourceware dot org>, <schwab at linux-m68k dot org>, <david dot holsgrove at xilinx dot com>, <aurel32 at debian dot org>
- Date: Tue, 25 Mar 2014 00:21:28 +0000
- Subject: Re: Correct robust mutex / PI futex kernel assumptions (bug 9894)
- Authentication-results: sourceware.org; auth=none
- References: <Pine dot LNX dot 4 dot 64 dot 1403242138500 dot 1129 at digraph dot polyomino dot org dot uk> <20140324 dot 182625 dot 1276142019211722152 dot davem at davemloft dot net>
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"?
--
Joseph S. Myers
joseph@codesourcery.com