From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752767AbcAZWdu (ORCPT ); Tue, 26 Jan 2016 17:33:50 -0500 Received: from mail-io0-f172.google.com ([209.85.223.172]:35862 "EHLO mail-io0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752548AbcAZWdm (ORCPT ); Tue, 26 Jan 2016 17:33:42 -0500 MIME-Version: 1.0 In-Reply-To: References: <20160114204827.GE3818@linux.vnet.ibm.com> <20160118081929.GA30420@gondor.apana.org.au> <20160118154629.GB3818@linux.vnet.ibm.com> <20160126165207.GB6029@fixme-laptop.cn.ibm.com> <20160126172227.GG6357@twins.programming.kicks-ass.net> <20160126201037.GU4503@linux.vnet.ibm.com> Date: Tue, 26 Jan 2016 14:33:40 -0800 X-Google-Sender-Auth: jrH1Y-2rPmX0XPeb1iHEl5cNOaA Message-ID: Subject: Re: [v3,11/41] mips: reuse asm-generic/barrier.h From: Linus Torvalds To: Paul McKenney Cc: Peter Zijlstra , Boqun Feng , Herbert Xu , Leonid Yegoshin , linux-mips , "linux-ia64@vger.kernel.org" , "Michael S. Tsirkin" , Will Deacon , virtualization , Peter Anvin , sparclinux@vger.kernel.org, Ingo Molnar , "linux-arch@vger.kernel.org" , linux-s390 , Russell King - ARM Linux , uml-devel , linux-sh@vger.kernel.org, Michael Ellerman , "the arch/x86 maintainers" , xen-devel@lists.xenproject.org, Ingo Molnar , linux-xtensa@linux-xtensa.org, James Hogan , Arnd Bergmann , Stefano Stabellini , adi-buildroot-devel@lists.sourceforge.net, David Daney , Thomas Gleixner , linux-metag@vger.kernel.org, "linux-arm-kernel@lists.infradead.org" , Andrew Cooper , Linux Kernel Mailing List , Ralf Baechle , Joe Perches , ppc-dev , David Miller Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jan 26, 2016 at 2:15 PM, Linus Torvalds wrote: > > You might as well just write it as > > struct foo x = READ_ONCE(*ptr); > x->bar = 5; > > because that "smp_read_barrier_depends()" does NOTHING wrt the second write. Just to clarify: on alpha it adds a memory barrier, but that memory barrier is useless. On non-alpha, it is a no-op, and obviously does nothing simply because it generates no code. So if anybody believes that the "smp_read_barrier_depends()" does something, they are *wrong*. And if anybody sends out an email with that smp_read_barrier_depends() in an example, they are actively just confusing other people, which is even worse than just being wrong. Which is why I jumped in. So stop perpetuating the myth that smp_read_barrier_depends() does something here. It does not. It's a bug, and it has become this "mind virus" for some people that seem to believe that it does something. I had to remove this crap once from the kernel already, see commit 105ff3cbf225 ("atomic: remove all traces of READ_ONCE_CTRL() and atomic*_read_ctrl()"). I don't want to ever see that broken construct again. And I want to make sure that everybody is educated about how broken it was. I'm extremely unhappy that it came up again. If it turns out that some architecture does actually need a barrier between a read and a dependent write, then that will mean that (a) we'll have to make up a _new_ barrier, because "smp_read_barrier_depends()" is not that barrier. We'll presumably then have to make that new barrier part of "rcu_derefence()" and friends. (b) we will have found an architecture with even worse memory ordering semantics than alpha, and we'll have to stop castigating alpha for being the worst memory ordering ever. but I sincerely hope that we'll never find that kind of broken architecture. Linus