Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp1248532pxa; Sat, 22 Aug 2020 17:41:39 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx8iiNDg+K6QOC5iLQ5jqFbZqZPv3t5VnD7klmZqTjOrmI6osNt5x4V9WFbLW9xNSWG4nbW X-Received: by 2002:a17:907:214e:: with SMTP id rk14mr1771ejb.171.1598143299535; Sat, 22 Aug 2020 17:41:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1598143299; cv=none; d=google.com; s=arc-20160816; b=0+y5hH3ZgTFPPkw1cubt4nq+lhVNaSUyb+quReGqy1mSpudx7F+b5kBPa9moYGFUx9 6xP7hCRcSak8a933iKfhngofJ0l+TfSC3Rjg2Qg1r/6DwipG/fWioTBTUVG7K/f21X3c BgunB3tnyoVwBCkPmbjTOQG3fGj40KGeqTHHWCBXlg40P3jTNalbBJnkKDhVFOHYkh9R B47X1tWQQQBNAkGNRB2x1OPfIJM7XYdtiLBIt/2hlWn3UCpjjim66U90RDtY29xeM6h1 vV0Tg+e/FC/muXjthlOZsqD8RipHaEdB+O6KdIZU8Lg0RffDr2rvtdFjamn4L9UrGSfs PWag== 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=YIkVDHiTfHwp9VvpwPx0pR6/gdoUoxP4akmJs/bN2QQ=; b=fiC0HMH3qKRnpevzunMuKh3Jgv0d2ogju2u0t7TTeOHDWYZUgbej2PTPrtoDPqXevp 6aPY2Un6eSHZiMMHDRfOvfx7f6/ywS2kiHqilbCbTIL0eDLRnSHRq+parjp76O4sngvG aovX3MHvnFKWS4uQP/Kb7wZcMGL8kbv2+GfNvqijpjy+Lpew6MXWwRBfJREbnqYPCQgr dHfjKLs9qWDe4vUOy8JKSaz1h3f7IVQK1QLe11pMqY2ZdCaPzXpT+wf8WkhqJGI1N86u lT5FgsujhkD/JMsJjXFTZ04TYidJTwIxeN/3sUheEXE4fWuPBCypA2bgaDtvAcizHbJh FjIg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=google header.b=dTw30b2J; 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 bf8si4122516edb.597.2020.08.22.17.41.15; Sat, 22 Aug 2020 17:41:39 -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=pass header.i=@linux-foundation.org header.s=google header.b=dTw30b2J; 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 S1728659AbgHWAKo (ORCPT + 99 others); Sat, 22 Aug 2020 20:10:44 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46152 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728434AbgHWAKn (ORCPT ); Sat, 22 Aug 2020 20:10:43 -0400 Received: from mail-lj1-x241.google.com (mail-lj1-x241.google.com [IPv6:2a00:1450:4864:20::241]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 79D48C061573 for ; Sat, 22 Aug 2020 17:10:42 -0700 (PDT) Received: by mail-lj1-x241.google.com with SMTP id 185so5747784ljj.7 for ; Sat, 22 Aug 2020 17:10:41 -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=YIkVDHiTfHwp9VvpwPx0pR6/gdoUoxP4akmJs/bN2QQ=; b=dTw30b2JGhzNFtqWpFzHbpuHuQK0LUZLpQyOlsdW4z28uyV5F5wMPq7Hbs/Nd5GgTW YG7B0STPDqSEY9nHy+oY8pAlsWAL6l6kpJPJrMqvCHOe7tgsnfSwMw4VE8LS+c1/9a+3 QhwTZl/ANBCM7KtvK0945P6zEu/p+m0DjZil0= 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=YIkVDHiTfHwp9VvpwPx0pR6/gdoUoxP4akmJs/bN2QQ=; b=nZH6OgNKbjStww90qldPHjlrPd/pV1To7MPDvu1TghiMRlv0WD5lzXHRM+Uv0HZabx j3Tt7Qc/+I9Yl8slvB8NWtcm41ivmzjCzVgVOCGK/KzN2gjWPRYgnXuiKuWq2Y516Q3S xjrwPSbSInZ+5o6K4ea9cucV6P7zUtfSTTSe0W4ulJDV2vSlkqHzmdvf4mUcCMBI+ggi mUItaAI0WcNK+3q5aC2TsYF5ck6EJVayUFNXi6RUPsxiYvltm4Hgawo9gIzWIFa1IT9U rR25SXb7qMghrDG0ODxnBQDF2ScRMlF4Cvc8a9Gsj/wl2qk9T1Iq0FhwQCg82B1Vlz8z bA4w== X-Gm-Message-State: AOAM5329bf2sITZY+PoFc0ILdFlXp4AaLC5st7aL+yb43Z4xfedl6fPy v3OOcHen1vIUyWipMbLFnZAjaU+8ozgyRA== X-Received: by 2002:a2e:808f:: with SMTP id i15mr4850048ljg.151.1598141440051; Sat, 22 Aug 2020 17:10:40 -0700 (PDT) Received: from mail-lj1-f182.google.com (mail-lj1-f182.google.com. [209.85.208.182]) by smtp.gmail.com with ESMTPSA id s2sm1262623ljm.4.2020.08.22.17.10.37 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 22 Aug 2020 17:10:38 -0700 (PDT) Received: by mail-lj1-f182.google.com with SMTP id t6so5733888ljk.9 for ; Sat, 22 Aug 2020 17:10:37 -0700 (PDT) X-Received: by 2002:a2e:7615:: with SMTP id r21mr4215256ljc.371.1598141437262; Sat, 22 Aug 2020 17:10:37 -0700 (PDT) MIME-Version: 1.0 References: <87zh6ohm03.fsf@nanos.tec.linutronix.de> <20200821230435.GA56974@rani.riverdale.lan> <87eenzqzmr.fsf@nanos.tec.linutronix.de> <20200822035552.GA104886@rani.riverdale.lan> <20200822084133.GL28786@gate.crashing.org> <20200822231055.GA1871205@rani.riverdale.lan> In-Reply-To: <20200822231055.GA1871205@rani.riverdale.lan> From: Linus Torvalds Date: Sat, 22 Aug 2020 17:10:21 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] x86: work around clang IAS bug referencing __force_order To: Arvind Sankar Cc: Miguel Ojeda , Sedat Dilek , Segher Boessenkool , Thomas Gleixner , Nick Desaulniers , "Paul E. McKenney" , 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 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 Sat, Aug 22, 2020 at 4:11 PM Arvind Sankar wrote: > > Actually, is a memory clobber required for correctness? Memory accesses > probably shouldn't be reordered across a CRn write. Is asm volatile > enough to stop that or do you need a memory clobber? You do need a memory clobber if you really care about ordering wrt normal memory references. That said, I'm not convinced we do care here. Normal memory accesses (as seen by the compiler) should be entirely immune to any changes we do wrt CRx registers. Because code that really fundamentally changes kernel mappings or access rules is already written in low-level assembler (eg the entry routines or bootup). Anything that relies on the more subtle changes (ie user space accesses etc) should already be ordered by other things - usually by the fact that they are also "asm volatile". But hey, maybe somebody can come up with an exception to that. Linus