Received: by 2002:a05:6a10:1a4d:0:0:0:0 with SMTP id nk13csp1278427pxb; Wed, 2 Feb 2022 00:50:49 -0800 (PST) X-Google-Smtp-Source: ABdhPJx3jxKAUkLhoV204/tmdFU19faq9lhxLoSNLQX9TiMbCbOFf/FiCIoZEcyZkdJfA2FmHIrh X-Received: by 2002:a17:907:60cd:: with SMTP id hv13mr24283882ejc.684.1643791848875; Wed, 02 Feb 2022 00:50:48 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643791848; cv=none; d=google.com; s=arc-20160816; b=UORDGKSyTb2vy+VR3kPY/Edvpif7EnQ34QPbTSfGl86LuxArKWMlcUpLkPnK1Qx3mD fFSCJARkz13Vj7fByDL4ns1w9+jwZpBEunpjpSt+6zNjXAGew/qfu1p3VIu5P03x1T9N C2Lf4XvwnibI6/WE6++HGeDNP4d8mo1tPJ00hX954XfMZJA98NeD49+1QIda57QLRqLV VvB+DxtTs/sqr7W48h5kYrkti4yFygsRZsTwnwFCWy3VuTtQziCcq5OXAbgW42Xog7VK ItcoaaUBEn/g2c+hvGc+7eqLOS8YtsVzZEwTxZHQxjGS0oMBuUgdkD7TZN9TIePWq52a DCFA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version; bh=hderlE7hTOGeYSej5CSKE+iXy7MLf7MK0wbUw69+glg=; b=WDKeRROeM82TfY+Nqwf2dnKeKr1N6W5aEwt25VHBf6lZcZkC3mxICHZBmIUy8/IDFw pHtCl9TOu5AxOSHP0jK+KbdgTux/mhtiKdx4oix2JmF13b6Dhpj+0aWCs5s4Jtw1W3/6 2/b7U7VOHgXBM4EfPsUG8Ds3Z/S+XCJet77FV6vHnQIpSmWypuWFHIupv1dZdCZ/o+kg 6C2s+TZ4JWEGjedAFPmW92PCtzkq9AkN14brUEfCloCCndy4XeRqFO4/ble3y+SoOvC4 OY41RCX5j5d/WWXByRzT++nljAF4bVpPB2FgHiweZJcd8Z5E3CwbxMCTnWd/hNGEuBUZ ckGg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id 7si10382333ejk.809.2022.02.02.00.50.24; Wed, 02 Feb 2022 00:50:48 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235085AbiBAHiK (ORCPT + 99 others); Tue, 1 Feb 2022 02:38:10 -0500 Received: from mout.kundenserver.de ([212.227.126.135]:43801 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235003AbiBAHiJ (ORCPT ); Tue, 1 Feb 2022 02:38:09 -0500 Received: from mail-oi1-f169.google.com ([209.85.167.169]) by mrelayeu.kundenserver.de (mreue010 [213.165.67.97]) with ESMTPSA (Nemesis) id 1Mk0a0-1mURRH1SY4-00kRXu; Tue, 01 Feb 2022 08:38:07 +0100 Received: by mail-oi1-f169.google.com with SMTP id v67so31649622oie.9; Mon, 31 Jan 2022 23:38:06 -0800 (PST) X-Gm-Message-State: AOAM532N9ip1dCa9ckyzxDsUhmIm9KBYNMWYqmjOas1B3C5kzDKGHmlg wZ+HI7LjqzoRur71jfwoBAlpDLF4c46yYImO2W4= X-Received: by 2002:aca:2b16:: with SMTP id i22mr389475oik.128.1643701085749; Mon, 31 Jan 2022 23:38:05 -0800 (PST) MIME-Version: 1.0 References: <20220131225250.409564-1-ndesaulniers@google.com> <202201311550.31EF589B2@keescook> In-Reply-To: <202201311550.31EF589B2@keescook> From: Arnd Bergmann Date: Tue, 1 Feb 2022 08:37:49 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] docs/memory-barriers.txt: volatile is not a barrier() substitute To: Kees Cook Cc: Nick Desaulniers , Jonathan Corbet , Josh Poimboeuf , Borislav Petkov , Peter Zijlstra , llvm@lists.linux.dev, Alan Stern , Andrea Parri , Will Deacon , Boqun Feng , Nicholas Piggin , David Howells , Jade Alglave , Luc Maranget , "Paul E. McKenney" , Akira Yokosawa , Daniel Lustig , Joel Fernandes , "Gustavo A. R. Silva" , Len Baker , Linux Kernel Mailing List , linux-arch , "open list:DOCUMENTATION" Content-Type: text/plain; charset="UTF-8" X-Provags-ID: V03:K1:Gmy/OLhhRhW8zXgYaS+K13GMv7b02GK61cdOOM+6a0V9RpMTBRD 9AZf23HLzhtQNorolU+10ZvdPFllQLfhoASYc+LIDhid4oeCN8ZtIlX/Y/sDVK1ntnzBVOB DklZH71DY5yvshzSPsPgmh6p9SsaBupSLM52BdsClj6SFiuFYJWAIGgdh6vaAsr91guMuxK gPCJ6vD1ntRemqEbfnLFA== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:DLjwZiIMbCI=:o7mkkKsFobMnUtaepxHD+S gaPs5kUQoIw4JQR7okiaEspEjxPX38TflIee5BdHC7wA0yP5ys131QpZJ4vX93uFP8ZAzDWah N03ZNmUpv4mewOe7vAr+ClRbmalcgK99hY5tf4M31dJkjmsD2MUq79r6TySUQnHkrOU1ZeZWu gzNSGVj2RBc66X8VkbjRNYAAmWsrUjzSZtUywWprwz0fxgeYowt6YyKct4rD/29Pu3Vnyb7ws sz3TYaCBtRMGictyhP9+BSsSJlJSdVU4xsOpT9WnHgWYABaTeoqXFG4+bLNbN7RUS25JuvTrb Dazubzl/dWUTJzNhL5uyy0thxc6Zs8Il2GrSGKe3F52pGViEE3duJj9UARByGWCpQe5plcZcS SN4ruQlGeT62iBvIMI8K6lK5BzgBmMqoo40Ms3v44X/1bnPOJ9W6QkQ97jSM0kkKqlpU3xMPY aqSzZ1Oqw2rd68Oev01F3A6mKndzwWGC0oJ/ve6wT09nsmuxku68s4/as/QWOGO1hHvGGEBln tz5kPQX0bCn6DPkWc4QLUZ7OMlaMHkWVGZwXvVP5SEnMk2bFgJLehlQC35zqUXEwn9+BQs4FR 6XNaOW/AAAz3IyYCBQbPsmjaRtm6PZDb5wYDeKL/E6vNOBw7S9pg1gNdmTPJhIdjjNCeL9g+n qGgzu0vzN1PkFUlLksoeCnlmnkq8+6OgRYGqD0rSMZYlH99vJZCcHDgM0yASH2njET1/BHSRJ QQjdm1f5dpbptxjUkwKHOaA9B58tJRPJ22xqjC38NhgcWPWOFCWhmqP30pBuVXNQ7ySaQtHdZ LZvN2iF9OUTbb9yIHNUpcf6LfQwZACUQrpOVj1WYoo0mjArkfA= Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 1, 2022 at 12:53 AM Kees Cook wrote: > > + > > +According to `the GCC docs on inline asm > > +https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#Volatile`_: > > + > > + asm statements that have no output operands and asm goto statements, > > + are implicitly volatile. > > Does this mean "volatile" _is_ needed when there are operands, etc? It depends on what you want to express. The idea here is to give a way to gcc for optimizing out anything with an output, like x86 rdtsc() when the result is not used, which is sensible. If there is no output, such as in writel(), you don't need 'volatile' because gcc can assume that an inline asm without outputs has side-effects already. A case where you need to add volatile is for (void)readl(ADDR), which is an operation that has an output as well as a side-effect. Arnd