Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751431Ab3GSTs2 (ORCPT ); Fri, 19 Jul 2013 15:48:28 -0400 Received: from mail-ve0-f173.google.com ([209.85.128.173]:40833 "EHLO mail-ve0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751117Ab3GSTs1 (ORCPT ); Fri, 19 Jul 2013 15:48:27 -0400 MIME-Version: 1.0 In-Reply-To: References: <20130719183101.GA20909@twins.programming.kicks-ass.net> <51E98EB4.3080307@hp.com> Date: Fri, 19 Jul 2013 12:48:26 -0700 X-Google-Sender-Auth: LcOMPo5qWoDKFO5a-S9QW0bDNvQ Message-ID: Subject: Re: [PATCH] mutex: Fix mutex_can_spin_on_owner From: Linus Torvalds To: Thomas Gleixner Cc: Waiman Long , Peter Zijlstra , Davidlohr Bueso , Rik van Riel , Andrew Morton , "Paul E. McKenney" , David Howells , Ingo Molnar , Linux Kernel Mailing List Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1439 Lines: 29 On Fri, Jul 19, 2013 at 12:41 PM, Thomas Gleixner wrote: > > That's true for your particular compiler, but it's not guaranteed at > all. So it matters even when your compiler generates the same > code. Others might not. There is a world outside of x8664. Well, in this case, I think we can pretty safely say that a compiler has to be seriously buggered to not just doit as a single load. If there are reloads in that sequence, the compiler is past bad. That said, I'm absolutely not arguing against the fix, and it needs to be done. Not so much because of "a compiler might screw it up" as simply because it's (a) the right thing to do and (b) documentation about the fact that we're doing special things that aren't really locked. In particular, I could imagine us some day checking that ACCESS_ONCE() accesses are never cacheline crossers or multiword accesses, neither of which may be atomic. A 64-bit ACCESS_ONCE on a 32-bit machine would be a bug, for example. Not that I think we do that, but the point is that ACCESS_ONCE() is about more than just compiler code generation. It's documentation, and it's a possible venue for sanity-checking. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/