glibc-2.5 test suite hangs/crashes the machine

[Steve Munroe]

Benjamin Herrenschmidt <benh at kernel.crashing.org> wrote on 11/01/2006
04:35:52 PM:

>
> > The tst-robustpi# test are exercising the new PTHREAD_MUXTEX_ROBUST
api,
> > with PTHREAD_PRIO_INHERIT attribute.
> >
> > The fuxtex word seems to include the waiters TID, I don't know if the
> > kernel cares about this or not.
>
> Ok, well, we have seen a few issues so far with these. 2 are kernel
> issues, but one might not be:
>
>  - kernels 2.6.15 .. .17 at least it seems wire the robust futex
> syscalls on powerpc without properly implementing the support, which can
> cause hangs in process exit. Do you have any way to "blacklist" kernels
> in glibc ?
>
>From libc/sysdeps/unix/sysv/linux/kernel-features.h

/* Support for inter-process robust mutexes was added in 2.6.17.  */
#if __LINUX_KERNEL_VERSION >= 0x020611
# define __ASSUME_SET_ROBUST_LIST       1
#endif

/* Support for PI futexes was added in 2.6.18.  */
#if __LINUX_KERNEL_VERSION >= 0x020612
# define __ASSUME_FUTEX_LOCK_PI 1
#endif

So I need to delay __ASSUME_SET_ROBUST_LIST to 2.6.18 for __powerpc__ ?

What about __ASSUME_FUTEX_LOCK_PI ?

>  - kernel 2.6.18 and current git until yesterday (fix got in today) has
> a bug if you manage to pass a wrong futex with a non-aligned atomic
> value, it will possibly oops the kernel. With the fix, it will return an
> error.
>
> Now what seems to be a glibc issue:
>
>  - I've had the tst-robustpi# tests (in fact the very first one, I
> haven't tested the others) die on me with a SIGBUS caused by glibc
> trying to do a lwarx/starx. on an odd address.
>
Rayn reminded me of a bug where the new robust code did not account for the
fact that the TID was not at the same place as i386. I think Ryan has a
patch.

Steven J. Munroe
Linux on Power Toolchain Architect
IBM Corporation, Linux Technology Center