Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp1224339pxa; Thu, 20 Aug 2020 06:08:09 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwdW6nUMi9HB+PI0jcTtgaZkzLVOBa/NFdWXR2yYi1j/7Mjumn2CV/dic4+UIUYDQNXvZ2A X-Received: by 2002:a17:906:824d:: with SMTP id f13mr3341791ejx.190.1597928888806; Thu, 20 Aug 2020 06:08:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1597928888; cv=none; d=google.com; s=arc-20160816; b=LjdTuXZ1mqNFb1ta8+7dxjxgt+8VlDh5MsZgVwcbcmfj7FaWhEffMKpDiutbj3NJOU tq4E9gI/c1C9z8Yqh0hAiydUiGCejWxpRmI7WjFxtpupY/c1nrsaNvF79HBIKUkBaxZy IAxQPw/EFkjAfCFNKH+e5sB76cz7z1+QpTFcDQS3zfOJNj/O9mq9d9+VYokO3G+nrYX6 cDvy/8th3TyPsvsprB6ow1iq3GEF8e7gZVU10SNYG0VP3so4jry2nQ797XXBa37cR3AG /1XU/Kzh47uy0MegL6qQdGKAwY0qnTkvPzm4s8Gg+iTDQMcbjUf1gvDec318rQRylUE7 3b7Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:date:from :dkim-signature; bh=6sOeSsarGxFkc/+IF5UxnDuuMZBTO6G7PiDa6w0ehU4=; b=irBQs77WVj3dEZRC68YDdc2+Awd0kNeH3piGEAHrx2RG57XGOVkmjbYzQFiNgB+Wcg 360c1tkC0W5O66kMOS835K3uwVZxdRnI05Zv8/2guQHpkoix/KPgSOhUpr7GYEnlg+TW I+Lebz71z7DuceMpURMkRHlfllWAhF0KQffp0tHVj3GeWp+HnkhStysYo4ui8xFN5gRz sJMcu/4NwS9WSCenKhEHmBa3YqmRBoIDSJ7B3Xu0S0T3WIBIIq8sZqXFrBnNCEGXYGLz mbbug9mxm8g4Esi9jki0hPBmv7dJTzXQ9OgMU4bbArR/KRsc3wvFERvRPKVJ/ktMITAj Z4MA== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=LM5GQuhF; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id z1si1151825eja.41.2020.08.20.06.07.42; Thu, 20 Aug 2020 06:08:08 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=LM5GQuhF; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728298AbgHTNHB (ORCPT + 99 others); Thu, 20 Aug 2020 09:07:01 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34150 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729453AbgHTNGp (ORCPT ); Thu, 20 Aug 2020 09:06:45 -0400 Received: from mail-qt1-x841.google.com (mail-qt1-x841.google.com [IPv6:2607:f8b0:4864:20::841]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 253DAC061385 for ; Thu, 20 Aug 2020 06:06:45 -0700 (PDT) Received: by mail-qt1-x841.google.com with SMTP id d27so1097337qtg.4 for ; Thu, 20 Aug 2020 06:06:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:date:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=6sOeSsarGxFkc/+IF5UxnDuuMZBTO6G7PiDa6w0ehU4=; b=LM5GQuhFGEsLF8MQ6iOdC11qBa7tnj8sX0Xil7PxLzz/UMQLxDRtcvKVnl1hsnEW3B icW4hW5rJquat9cuaRLYXwjPc69Id1R75PgEiZK66cy0exPj/r3d8qLlYwhkS18l5ifx 73P1btmYPz9Qg/EwV8gf+/md6kgGYdrBDEw0GA1l/HYrJ5vU6uwgZQAB+Pk5iKxaDaPj p6NJ/ajFj2loXTCG/WdpbtmPs4jlcnvtQ+yOu2dbQcLz8I6nDj2yEkE7YDSZ6DgwNywy /ByoGAJ4Q1GtihDUQfhHQlVhNEp7M0JSHZFztUT7nMAmHo2nRwLUhBsT9/toWMJ2uZIk ebSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:date:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=6sOeSsarGxFkc/+IF5UxnDuuMZBTO6G7PiDa6w0ehU4=; b=Vz/ZLVX8Z/Ti8x3o3EZxlJoDwTBrTLIw0mkVq9S5m+hEOjD4X6NAK1h3KllGvZuvlZ iNBFeSmjnULzgncffXSw0kc7wonIc+ofyJTZKw3W2UKXLE2BoKbmDhBE5XcPJAxlgy3U uBR5RDrNopu/3KwFzulkgXwq8k7tIdNGFSIJHptC1MAjRhp6CjmEr40yYPH0B1jxmgVs jo6j6mf4SJ8aRR4PqA21Epf44cIGgAlDDr6pvuVNXGzhxBhBJtRPki7XGjXp1YkoDC/N fDcjG20qERiBj/8gBxnM2/fItRquOexzd+ZVCoymztYRLoLqhtg2slRYgW5xOBAbyZfs Veyg== X-Gm-Message-State: AOAM5313N7Hpnn3Ab7OICHPnvg1mzRy3/Gd9KWvgcUBuoAaFvekCAAa5 xdkiLlFCHWCHllmWWuCCJUw= X-Received: by 2002:ac8:4e91:: with SMTP id 17mr2582988qtp.284.1597928804224; Thu, 20 Aug 2020 06:06:44 -0700 (PDT) Received: from rani.riverdale.lan ([2001:470:1f07:5f3::b55f]) by smtp.gmail.com with ESMTPSA id q126sm1998857qke.34.2020.08.20.06.06.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 20 Aug 2020 06:06:43 -0700 (PDT) From: Arvind Sankar X-Google-Original-From: Arvind Sankar Date: Thu, 20 Aug 2020 09:06:41 -0400 To: Thomas Gleixner Cc: Arvind Sankar , "Paul E. McKenney" , Nick Desaulniers , Ingo Molnar , Arnd Bergmann , Borislav Petkov , "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" , "H. Peter Anvin" , "Kirill A. Shutemov" , Zhenzhong Duan , Kees Cook , Peter Zijlstra , Juergen Gross , Andy Lutomirski , Andrew Cooper , LKML , clang-built-linux , Will Deacon , Linus Torvalds Subject: Re: [PATCH] x86: work around clang IAS bug referencing __force_order Message-ID: <20200820130641.GA536306@rani.riverdale.lan> References: <20200527135329.1172644-1-arnd@arndb.de> <878serh1b9.fsf@nanos.tec.linutronix.de> <87h7t6tpye.fsf@nanos.tec.linutronix.de> <20200813173701.GC4295@paulmck-ThinkPad-P72> <20200813180933.GA532283@rani.riverdale.lan> <875z9dioll.fsf@nanos.tec.linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <875z9dioll.fsf@nanos.tec.linutronix.de> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Aug 20, 2020 at 12:44:06PM +0200, Thomas Gleixner wrote: > On Thu, Aug 13 2020 at 14:09, Arvind Sankar wrote: > > On Thu, Aug 13, 2020 at 10:37:01AM -0700, Paul E. McKenney wrote: > >> > Let me ask (hopefully) useful questions this time: > >> > > >> > Is a compiler allowed to reorder two 'asm volatile()'? > >> > > >> > Are there compilers (gcc >= 4.9 or other supported ones) which do that? > >> > >> I would hope that the answer to both of these questions is "no"! > >> > >> But I freely confess that I have been disappointed before on this sort > >> of thing. :-/ > >> > >> Thanx, Paul > > > > Ok, I found this, so gcc developers consider re-ordering volatile asm > > wrt each other a bug at least. > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82602 > > Yes. It prevents reordering of volatiles, but it does not necessarily > prevent reorder of something like this: > > asm volatile(...); > foo(); > asm volatile(...); > > it might turn that into > > foo(); > asm volatile(...); > asm volatile(...); > > if I understood their discussion correctly. So removing this magic is > not really straight forward. > > Thanks, > > tglx > > I don't think that's an issue, or at least, not one where force_order helps. If the source for foo() is not visible to the compiler, the only reason force_order prevents the reordering is because foo() might have references to it, but equally foo() might have volatile asm, so the reordering isn't possible anyway. If the source is visible, force_order won't prevent any reordering except across references to force_order, but the only references are from the volatile asm's which already prevent reordering. I think force_order can only help with buggy compilers, and for those it should really have been an input-output operand -- it wouldn't currently do anything to prevent cr writes from being reordered. Thanks.