From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25119 invoked by alias); 4 Oct 2012 17:56:23 -0000 Received: (qmail 24850 invoked by uid 48); 4 Oct 2012 17:55:55 -0000 From: "bugdal at aerifal dot cx" 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 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: nptl X-Bugzilla-Keywords: X-Bugzilla-Severity: critical X-Bugzilla-Who: bugdal at aerifal dot cx X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: drepper.fsp at gmail dot com X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org X-SW-Source: 2012-10/txt/msg00060.txt.bz2 http://sourceware.org/bugzilla/show_bug.cgi?id=13184 --- Comment #11 from Rich Felker 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 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.