public inbox for glibc-bugs@sourceware.org help / color / mirror / Atom feed
From: "bugdal at aerifal dot cx" <sourceware-bugzilla@sourceware.org> To: glibc-bugs@sources.redhat.com Subject: [Bug nptl/13184] rwlocks can go into dead lock Date: Thu, 04 Oct 2012 17:56:00 -0000 [thread overview] Message-ID: <bug-13184-131-VXOflgaVXw@http.sourceware.org/bugzilla/> (raw) In-Reply-To: <bug-13184-131@http.sourceware.org/bugzilla/> http://sourceware.org/bugzilla/show_bug.cgi?id=13184 --- Comment #11 from Rich Felker <bugdal at aerifal dot cx> 2012-10-04 17:55:54 UTC --- I agree that it's ridiculous to try to fix a hardware bug like this. The kernel really should just refuse to do SMP on broken hardware like this unless it can do a transparent workaround in kernelspace. Then AMD can deal with replacing all the broken CPUs they sold when people start complaining that SMP no longer works. Atomic ops being broken and needing workarounds is not part of the x86 or x86_64 ABI. With that said, it would be nice to understand the bug. Is is that lock-prefixed read-modify-write operations (like "lock;inc (%reg)") get reordered with respect to xchg or lock-prefixed cmpxchg? Or is it only non-lock-prefixed read-modify-write operations (like "inc (%reg)") that are getting reordered with respect to the latter? I don't think there's any workaround that would not incur significant costs on non-broken systems, and even if there were, I think "fixing" this is wrong in principle. --- Comment #12 from Rich Felker <bugdal at aerifal dot cx> 2012-10-04 17:55:54 UTC --- I agree that it's ridiculous to try to fix a hardware bug like this. The kernel really should just refuse to do SMP on broken hardware like this unless it can do a transparent workaround in kernelspace. Then AMD can deal with replacing all the broken CPUs they sold when people start complaining that SMP no longer works. Atomic ops being broken and needing workarounds is not part of the x86 or x86_64 ABI. With that said, it would be nice to understand the bug. Is is that lock-prefixed read-modify-write operations (like "lock;inc (%reg)") get reordered with respect to xchg or lock-prefixed cmpxchg? Or is it only non-lock-prefixed read-modify-write operations (like "inc (%reg)") that are getting reordered with respect to the latter? I don't think there's any workaround that would not incur significant costs on non-broken systems, and even if there were, I think "fixing" this is wrong in principle. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
next prev parent reply other threads:[~2012-10-04 17:56 UTC|newest] Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top 2011-09-12 21:19 [Bug nptl/13184] New: " redhat at pureftpd dot org 2011-09-12 21:33 ` [Bug nptl/13184] " bugdal at aerifal dot cx 2011-09-12 21:42 ` redhat at pureftpd dot org 2011-09-12 22:26 ` bugdal at aerifal dot cx 2011-09-12 22:41 ` redhat at pureftpd dot org 2011-09-13 1:57 ` redhat at pureftpd dot org 2011-09-13 2:02 ` redhat at pureftpd dot org 2012-01-16 20:03 ` ph.mathieu at gmail dot com 2012-01-16 21:47 ` redhat at pureftpd dot org 2012-01-17 14:54 ` ph.mathieu at gmail dot com 2012-10-04 12:31 ` siddhesh at redhat dot com 2012-10-04 12:37 ` bugdal at aerifal dot cx 2012-10-04 13:13 ` siddhesh at redhat dot com 2012-10-04 17:56 ` bugdal at aerifal dot cx [this message] 2012-10-04 17:56 ` bugdal at aerifal dot cx 2012-12-19 10:44 ` schwab@linux-m68k.org 2014-06-13 14:29 ` fweimer at redhat dot com
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=bug-13184-131-VXOflgaVXw@http.sourceware.org/bugzilla/ \ --to=sourceware-bugzilla@sourceware.org \ --cc=glibc-bugs@sources.redhat.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: linkBe 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 read-only IMAP folder(s) and NNTP newsgroup(s).