This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug nptl/13184] rwlocks can go into dead lock
- From: "bugdal at aerifal dot cx" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sources dot redhat dot com
- Date: Thu, 04 Oct 2012 17:55:54 +0000
- Subject: [Bug nptl/13184] rwlocks can go into dead lock
- Auto-submitted: auto-generated
- References: <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.