From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Steve Munroe <sjmunroe@us.ibm.com>
Cc: linuxppc-dev@ozlabs.org, Jeff Bailey <jbailey@ubuntu.com>,
Fabio Massimo Di Nitto <fabbione@ubuntu.com>,
Paul Mackerras <paulus@samba.org>,
Ben Collins <ben.collins@ubuntu.com>
Subject: Re: glibc-2.5 test suite hangs/crashes the machine
Date: Thu, 02 Nov 2006 09:35:52 +1100 [thread overview]
Message-ID: <1162420552.25682.471.camel@localhost.localdomain> (raw)
In-Reply-To: <OF160F7BCC.ADD0D85F-ON86257219.00795AB5-86257219.007A72E6@us.ibm.com>
> 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 ?
- 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.
I do not know for sure yet if the crash reported by Fabio with 2.6.19
(before my fix above) was related to the same kind of misaligned futex
managing to reach the kernel and triggering the oops I've talked about,
but it's very possible.
In my case, glibc was built against 2.6.16 headers, in fabio case, I
think it was built against 2.6.15 or .17 headers. It -seems- that fabio
cannot reproduce the problem when building glibc against 2.6.19 headers,
though at this point I can't explain why and I haven't reproduced here
yet.
Do you have any insight in what might be happening or should we just dig
more ?
Cheers,
Ben.
next prev parent reply other threads:[~2006-11-01 22:37 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-27 5:56 glibc-2.5 test suite hangs/crashes the machine Fabio Massimo Di Nitto
2006-10-27 16:22 ` Jeff Bailey
2006-10-30 1:47 ` Benjamin Herrenschmidt
2006-11-01 22:17 ` Steve Munroe
2006-11-01 22:35 ` Benjamin Herrenschmidt [this message]
2006-11-01 22:56 ` Steve Munroe
2006-11-01 23:22 ` Benjamin Herrenschmidt
2006-10-30 3:02 ` Benjamin Herrenschmidt
2006-10-30 11:35 ` Fabio Massimo Di Nitto
2006-10-30 20:36 ` Benjamin Herrenschmidt
2006-10-31 6:37 ` Fabio Massimo Di Nitto
2006-10-31 6:51 ` Fabio Massimo Di Nitto
2006-10-31 9:47 ` Fabio Massimo Di Nitto
2006-10-31 20:30 ` Benjamin Herrenschmidt
2006-10-31 20:44 ` Fabio Massimo Di Nitto
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1162420552.25682.471.camel@localhost.localdomain \
--to=benh@kernel.crashing.org \
--cc=ben.collins@ubuntu.com \
--cc=fabbione@ubuntu.com \
--cc=jbailey@ubuntu.com \
--cc=linuxppc-dev@ozlabs.org \
--cc=paulus@samba.org \
--cc=sjmunroe@us.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).