From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_NEOMUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id F2266C282CE for ; Wed, 5 Jun 2019 02:21:34 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id BE4E820828 for ; Wed, 5 Jun 2019 02:21:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726537AbfFECVe (ORCPT ); Tue, 4 Jun 2019 22:21:34 -0400 Received: from helcar.hmeau.com ([216.24.177.18]:52958 "EHLO deadmen.hmeau.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726293AbfFECVd (ORCPT ); Tue, 4 Jun 2019 22:21:33 -0400 Received: from gondobar.mordor.me.apana.org.au ([192.168.128.4] helo=gondobar) by deadmen.hmeau.com with esmtps (Exim 4.89 #2 (Debian)) id 1hYLYL-0004MT-Ux; Wed, 05 Jun 2019 10:21:26 +0800 Received: from herbert by gondobar with local (Exim 4.89) (envelope-from ) id 1hYLYD-0001by-GF; Wed, 05 Jun 2019 10:21:17 +0800 Date: Wed, 5 Jun 2019 10:21:17 +0800 From: Herbert Xu To: "Paul E. McKenney" Cc: Linus Torvalds , Frederic Weisbecker , Boqun Feng , Fengguang Wu , LKP , LKML , Netdev , "David S. Miller" Subject: Re: rcu_read_lock lost its compiler barrier Message-ID: <20190605022117.kw6tldcwhdkyqd6u@gondor.apana.org.au> References: <20150921193045.GA13674@lerouge> <20150921204327.GH4029@linux.vnet.ibm.com> <20190602055607.bk5vgmwjvvt4wejd@gondor.apana.org.au> <20190603000617.GD28207@linux.ibm.com> <20190603030324.kl3bckqmebzis2vw@gondor.apana.org.au> <20190603195304.GK28207@linux.ibm.com> <20190604211449.GU28207@linux.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190604211449.GU28207@linux.ibm.com> User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jun 04, 2019 at 02:14:49PM -0700, Paul E. McKenney wrote: > > Yeah, I know, even with the "volatile" keyword, it is not entirely clear > how much reordering the compiler is allowed to do. I was relying on > https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html, which says: The volatile keyword doesn't give any guarantees of this kind. The key to ensuring ordering between unrelated variable/register reads/writes is the memory clobber: 6.47.2.6 Clobbers and Scratch Registers ... "memory" The "memory" clobber tells the compiler that the assembly code performs memory reads or writes to items other than those listed in the input and output operands (for example, accessing the memory pointed to by one of the input parameters). To ensure memory contains correct values, GCC may need to flush specific register values to memory before executing the asm. Further, the compiler does not assume that any values read from memory before an asm remain unchanged after that asm; it reloads them as needed. Using the "memory" clobber effectively forms a read/write memory barrier for the compiler. Note that this clobber does not prevent the processor from doing speculative reads past the asm statement. To prevent that, you need processor-specific fence instructions. IOW you need a barrier(). Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============4433205268084170717==" MIME-Version: 1.0 From: Herbert Xu To: lkp@lists.01.org Subject: Re: rcu_read_lock lost its compiler barrier Date: Wed, 05 Jun 2019 10:21:17 +0800 Message-ID: <20190605022117.kw6tldcwhdkyqd6u@gondor.apana.org.au> In-Reply-To: <20190604211449.GU28207@linux.ibm.com> List-Id: --===============4433205268084170717== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Tue, Jun 04, 2019 at 02:14:49PM -0700, Paul E. McKenney wrote: > > Yeah, I know, even with the "volatile" keyword, it is not entirely clear > how much reordering the compiler is allowed to do. I was relying on > https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html, which says: The volatile keyword doesn't give any guarantees of this kind. The key to ensuring ordering between unrelated variable/register reads/writes is the memory clobber: 6.47.2.6 Clobbers and Scratch Registers ... "memory" The "memory" clobber tells the compiler that the assembly code performs memory reads or writes to items other than those listed in the input and output operands (for example, accessing the memory pointed to by one of the input parameters). To ensure memory contains correct values, GCC may need to flush specific register values to memory before executing the asm. Further, the compiler does not assume that any values read from memory before an asm remain unchanged after that asm; it reloads them as needed. Using the "memory" clobber effectively forms a read/write memory barrier for the compiler. Note that this clobber does not prevent the processor from doing speculative reads past the asm statement. To prevent that, you need processor-specific fence instructions. IOW you need a barrier(). Thanks, -- = Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --===============4433205268084170717==--