This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Memory fencing problem in pthread cancellation

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 ();
    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

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]