This is the mail archive of the glibc-bugs@sourceware.org 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]

[Bug nptl/13184] rwlocks can go into dead lock


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.


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