This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] [BZ 18463] ARM - fix PI mutex breakge
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Marc Kleine-Budde <mkl at pengutronix dot de>
- Cc: <libc-alpha at sourceware dot org>, <kernel at pengutronix dot de>
- Date: Wed, 22 Jul 2015 16:31:16 +0000
- Subject: Re: [PATCH] [BZ 18463] ARM - fix PI mutex breakge
- Authentication-results: sourceware.org; auth=none
- References: <1437396845-19469-1-git-send-email-mkl at pengutronix dot de>
On Mon, 20 Jul 2015, Marc Kleine-Budde wrote:
> This patch removes the "undef __ASSUME_REQUEUE_PI" to fix the issue.
Nothing in your explanation says why this should be ARM-specific.
You seem to be asserting that the semantics of __ASSUME_REQUEUE_PI are
something other than "PI futexes work with FUTEX_*_REQUEUE_PI support in
the kernel" - or at least, something other than (given the 2.6.32 minimum
kernel version) "futex_atomic_cmpxchg_inatomic is supported".
What are the semantics of __ASSUME_REQUEUE_PI? Your analysis only refers
to one use of that macro; you need to examine all such uses. Then, if the
reference to futex_atomic_cmpxchg_inatomic in
sysdeps/unix/sysv/linux/kernel-features.h is incorrect, you need to update
the comment on the definition there of __ASSUME_REQUEUE_PI so that it
accurately reflects the circumstances under which it is correct, or
incorrect, for that macro to be defined on particular architectures.
(That might mean adding an explanation of the semantics of the macro to
that comment that makes clear why it's desirable to define it even if PI
futexes might not be supported at runtime, for example.) Then, each
architecture that may undefine __ASSUME_REQUEUE_PI needs to be updated to
be consistent with the clarified (and documented) understanding of the
semantics of that macro - rather than just changing one architecture in
isolation without justification for the undefining being correct for the
Joseph S. Myers