Re: [PATCH] Memory fencing problem in pthread cancellation

[Mike Frysinger <vapier at gentoo dot org>]

On Monday 14 January 2013 15:24:09 Jeff Law wrote:
> This has been observed on a 32 processor power7 machine running 16
> instances of the attached testcase in parallel after a period of several
> hours.

i let 3 run on an ia64 dual core box for about 12 hrs and didn't see failures.  
which isn't to say there isn't a bug, just providing some data.

> While investigating, Carlos identified that the IA64 and ARM ports have
> their own unwind-forcedunwind.c implementations and that they were buggy
> in regards to fencing as well.  Both fail to test libgcc_s_handle and do
> not have the necessary calls to atomic_read_barrier.  This patch fixes
> those issues as well.
> 
> While I have extensively tested the generic unwind-forcedunwind.c change
> backported to a glibc-2.12 base, I have not checked the ARM or IA64 bits
> in any way.

the ia64 part looks (and runs) fine.

> -  if (__builtin_expect (libgcc_s_personality == NULL, 0))
> +  if (__builtin_expect (libgcc_s_handle == NULL, 0))

while you're here, might i suggest also doing:
	if (__glibc_unlikely (libgcc_s_handle == NULL))

perhaps we should even go further and make this an inline func in 
nptl/sysdeps/pthread/unwind-forcedunwind.c ?
static __always_inline void
_maybe_pthread_cancel_init (void)
{
  if (__glibc_unlikely (libgcc_s_handle == NULL))
    pthread_cancel_init ();
  else
    atomic_read_barrier ();
}

that way it's harder for arches to screw up because they just call:
	_maybe_pthread_cancel_init ();
and all the magic logic stays in the common unwind file
-mike

Attachment: signature.asc
Description: This is a digitally signed message part.