Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp4304747ybi; Mon, 3 Jun 2019 08:44:54 -0700 (PDT) X-Google-Smtp-Source: APXvYqwMKH7OYBG8EK1NRF4a5AkoBmbpwtLT9k02eY8dV16WuejhyxAqe7uilM3lz3i5xliUo1vP X-Received: by 2002:aa7:8a95:: with SMTP id a21mr32202585pfc.215.1559576694846; Mon, 03 Jun 2019 08:44:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1559576694; cv=none; d=google.com; s=arc-20160816; b=Yp8d/NBmR49J6kSKb1vWJmzqOVcy1657m8qW2gHzMlGiJNljWVxFIrztUKkgvxKkVf WLrRxe/1tYB1IxrB7kLOfSI2VQ88kttmEin1CivdbXg2Wq9ZOLZ8ciX73j8lzY8o52y6 c75A7C9eWZkBwiEr+23YMxZQx7lTr5Uq5u/BSHJ2QaBazHD194wp/GhgM0FPqQrblDWh K4EUkNgInHlI2SnXELOYc3RtgB4/Q0ZpZZCRhdXWmHasg6QmKJVs/tZWIEyYLOJ5e8MD NEQGblPvk9yk0uQ/YMMQl2f8NQMCDYhdVPjHUVDyK2sWdPWBlnHfRmNvcpolgYlEJJav W/EQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=88zEtlZo9VcPYvQYA1jKvAsBkyo9fzTE6nwo1Hgnw4c=; b=jnqKhVJn7u9ge9Codl35ZNza3+nq1rNI08ukHvzRigMvPnfzoHVFfZ+Qs99VrmGn+u oR8uNKgfqNNdfQmKMPpCZJ92w0mgEqS5k6vABGNzqiHgZJt3T53Quj4s2oCtVjyyPGPV HBnxP4v+d//Rthkt9jc/5i004wKfWA99NbvgFmKCzrV6f7xgKn8VHWRd0UTSKuWVEySE 3Wem42xLVfVm8NR12jwyRqJ3MHDmT+YqEQwsmEw4gO5paK1E0RpZ5302+LNwX5WgF0Mh ibcCfY/KF5l8Z05+zQxlT64RuhQRVz5YhodO4WkZ+ExB2WPCewyMgGXocaDniey3Mnji macw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=google header.b=g7xyhXor; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j59si19852791plb.176.2019.06.03.08.44.37; Mon, 03 Jun 2019 08:44:54 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=google header.b=g7xyhXor; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728024AbfFCPlD (ORCPT + 99 others); Mon, 3 Jun 2019 11:41:03 -0400 Received: from mail-lf1-f43.google.com ([209.85.167.43]:43862 "EHLO mail-lf1-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727649AbfFCPlB (ORCPT ); Mon, 3 Jun 2019 11:41:01 -0400 Received: by mail-lf1-f43.google.com with SMTP id j29so54308lfk.10 for ; Mon, 03 Jun 2019 08:41:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=88zEtlZo9VcPYvQYA1jKvAsBkyo9fzTE6nwo1Hgnw4c=; b=g7xyhXorBa6FBLPRxz237Si+Si/iS47DotxTNT9gS16OG4gjNWyRGb5dCcvnI/8QvX xq3WRPTwie1oOh6i5GON8NUyBCfTnraWU9T+b3l1nrZg7dNuzHbATVP6/ijneNfXZlNj GO03Ng2cp1/WOXDZ9RS2z8kXYjDpjQg1kccFQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=88zEtlZo9VcPYvQYA1jKvAsBkyo9fzTE6nwo1Hgnw4c=; b=gO5iXLwsHyPCAyRd4P8ku97KfUKitv9/ul+4Ldy+JDVH8FqwMswVdIc3SvbaMqrjcP kxNiSHdr4TN7f1KiRoNXbeivZq04slV9aSFYzJ+9SUbzH9TYCb52i46y6b+xvKP44SIC ebNfZsjRIDs2QORhamvpSsFt7av62H4IOyXIklJROtCMQk6vlrbq246CwNkuyi1V6AKH bQgQuA+3vLaXGxArauZc9n1ioGLsuE25rZ8Pa6BX2eHThVAryMKbJRFL37mmzgo3p+D7 Why8Ky05o3mqLwOFkbotOpK4la6JXlS9YVi7m4VcpPwrKHcW5N/08TNBZUyXEXnnM7My GZJA== X-Gm-Message-State: APjAAAUL2m++qvrWFOEf/q2LqgO7YaDorNMFbsUFIRVrjgQwrYmciaga wa392gihE3ewDTtZ7kpXNAGJqF8XOJw= X-Received: by 2002:a19:e308:: with SMTP id a8mr13573829lfh.69.1559576458739; Mon, 03 Jun 2019 08:40:58 -0700 (PDT) Received: from mail-lj1-f176.google.com (mail-lj1-f176.google.com. [209.85.208.176]) by smtp.gmail.com with ESMTPSA id a18sm1227030ljf.35.2019.06.03.08.40.57 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Jun 2019 08:40:57 -0700 (PDT) Received: by mail-lj1-f176.google.com with SMTP id a21so1466813ljh.7 for ; Mon, 03 Jun 2019 08:40:57 -0700 (PDT) X-Received: by 2002:a2e:9ad1:: with SMTP id p17mr14530773ljj.147.1559576456787; Mon, 03 Jun 2019 08:40:56 -0700 (PDT) MIME-Version: 1.0 References: <20150910171649.GE4029@linux.vnet.ibm.com> <20150911021933.GA1521@fixme-laptop.cn.ibm.com> <20150921193045.GA13674@lerouge> <20150921204327.GH4029@linux.vnet.ibm.com> <20190602055607.bk5vgmwjvvt4wejd@gondor.apana.org.au> <20190603024640.2soysu4rpkwjuash@gondor.apana.org.au> <20190603034707.GG28207@linux.ibm.com> <20190603040114.st646bujtgyu7adn@gondor.apana.org.au> <20190603072339.GH28207@linux.ibm.com> <20190603084214.GA1496@linux.ibm.com> <9c0a9e2faae7404cb712f57910c8db34@AcuMS.aculab.com> In-Reply-To: <9c0a9e2faae7404cb712f57910c8db34@AcuMS.aculab.com> From: Linus Torvalds Date: Mon, 3 Jun 2019 08:40:40 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: rcu_read_lock lost its compiler barrier To: David Laight Cc: "paulmck@linux.ibm.com" , Herbert Xu , Frederic Weisbecker , Boqun Feng , Fengguang Wu , LKP , LKML , Netdev , "David S. Miller" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jun 3, 2019 at 8:26 AM David Laight wrote: > > From: Paul E. McKenney > > > We do > > occasionally use READ_ONCE() to prevent load-fusing optimizations that > > would otherwise cause the compiler to turn while-loops into if-statements > > guarding infinite loops. > > In that case the variable ought to be volatile... No. We do not use volatile on variables. The C people got the semantics wrong, probably because 'volatile' was historically for IO, not for access atomicity without locking. It's not the memory location that is volatile, it is really the _access_ that is volatile. The same memory location might be completely stable in other access situations (ie when done under a lock). In other words, we should *never* use volatile in the kernel. It's fundamentally mis-designed for modern use. (Of course, we then can use volatile in a cast in code, which drives some compiler people crazy, but that's because said compiler people don't care about reality, they care about some paperwork). Linus