Message ID | 20221022114425.038102604@infradead.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:4242:0:0:0:0:0 with SMTP id s2csp1169141wrr; Sat, 22 Oct 2022 04:52:39 -0700 (PDT) X-Google-Smtp-Source: AMsMyM7ZnOpDMBhRAbbIqm1zJN7nKDqoPNBerndbdB/aXhzE4sMrW6y7xWOzkaLxg88qPnVCQlKE X-Received: by 2002:a05:6a00:16c4:b0:535:890:d4a with SMTP id l4-20020a056a0016c400b0053508900d4amr24255287pfc.0.1666439558857; Sat, 22 Oct 2022 04:52:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666439558; cv=none; d=google.com; s=arc-20160816; b=B1z3VeckI3fIIr5OtZfdX+jgi9jqsiUewUzOa1Sz3cKbwQcF4T4nVvIIz+TEpmihIX veuOp+ijL6h+Ya02fXMtrB1qKI6v9n6J6RXu422V8DyUDwZelWM23D+QRWxZZ77kCpp3 ybBjS9LSEx57DhNwsYwnjO6mmsePRnz8t3nT0yLOImJo2qSzU7RR9nwGq8JMrJazHiho iZiT0NyTP8KS7sd8MEScg9hkJBKU5LkNU7Fiy4+8vRiYgf83jY+JQDcpyRttVf6WzN9a 44c/DPhLtEXPjpy6uKMMMGGvLQuxNQOmGyDntGJNfhmYPsxmqZJN5xOOp3pgUKokFG1r fTZA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:references:subject:cc:to:from:date :user-agent:message-id:dkim-signature; bh=21hb22ZOLPug1Y7rU1MItuB/yDHg1vIxzPuc1LZH5hI=; b=BCqprHtcO6yntmlSM07ixhb+Kr6QBbLoYWwW4H4HQT27M1olwKIX8J7atThwxp1doz qlPEVXz4qkC32tmPj3X6AB/lg0Ied+HAjDMUNpBMBhR0d+knzGCuKaoSHZI21atYtt9v wNtF1lsEUvOUmu7eLgsa4yEgRzXD13n6oydBGSzJTdEZ1Io1kDg7/ybkVSukPCNl9GN+ PJQTECRYyMtb/SO7wbb25f6hraNH33Kwtc4mpfaRGcwd4rx522K1tZd4J0STK7ipJkNT JA3APMbIQ2/M64tqKaJdBRkpBMtAiRIoUHf7dOL//8pJTrcBFa6CGU+WpMk55ALNBD9a AL0g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@infradead.org header.s=desiato.20200630 header.b=PdKGQbC1; 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: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id h8-20020a170902f70800b0017f59ed2dfasi26325973plo.63.2022.10.22.04.52.26; Sat, 22 Oct 2022 04:52:38 -0700 (PDT) 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; dkim=pass header.i=@infradead.org header.s=desiato.20200630 header.b=PdKGQbC1; 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 S229900AbiJVLt3 (ORCPT <rfc822;pwkd43@gmail.com> + 99 others); Sat, 22 Oct 2022 07:49:29 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43524 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229945AbiJVLs4 (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Sat, 22 Oct 2022 07:48:56 -0400 Received: from desiato.infradead.org (desiato.infradead.org [IPv6:2001:8b0:10b:1:d65d:64ff:fe57:4e05]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D9C9E251D4F for <linux-kernel@vger.kernel.org>; Sat, 22 Oct 2022 04:48:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=desiato.20200630; h=Content-Type:MIME-Version:References: Subject:Cc:To:From:Date:Message-ID:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:In-Reply-To; bh=21hb22ZOLPug1Y7rU1MItuB/yDHg1vIxzPuc1LZH5hI=; b=PdKGQbC12QBugaGBHXI+1OdOwW jIeT7sZU8f/cCzbk9SkQJaFP1b540Ku1IBJuuSIHSLzg9x2w8Wmc8o276uAHPOpXzXLG3d6TZq0tF ufch0SOHGlt6rJ9GjVJv7If3PI2CCLHZEcs/plOsipgGDnY0U9T2MARB4MNF2md4sW8rQWFDyYM2z ftKN36vAn858VDWdBe2+QF71E9pc0xQfcgKilAvXMfbC3SKqEsFNp+XKGyHGw+FG2kU27DviLQ2k2 Zgve+Gbb5vgj55/AffmFiNzVSPKfRJE8lA9PCBRfZ7JGWZYdwkJx6h4LWZv/Y1jswpVYaPfpTSW4b 7CjP2Teg==; Received: from j130084.upc-j.chello.nl ([24.132.130.84] helo=noisy.programming.kicks-ass.net) by desiato.infradead.org with esmtpsa (Exim 4.94.2 #2 (Red Hat Linux)) id 1omCzM-005XdH-1s; Sat, 22 Oct 2022 11:48:28 +0000 Received: from hirez.programming.kicks-ass.net (hirez.programming.kicks-ass.net [192.168.1.225]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by noisy.programming.kicks-ass.net (Postfix) with ESMTPS id BDB8D302D91; Sat, 22 Oct 2022 13:48:26 +0200 (CEST) Received: by hirez.programming.kicks-ass.net (Postfix, from userid 0) id 3B49F28B8E516; Sat, 22 Oct 2022 13:48:26 +0200 (CEST) Message-ID: <20221022114425.038102604@infradead.org> User-Agent: quilt/0.66 Date: Sat, 22 Oct 2022 13:14:12 +0200 From: Peter Zijlstra <peterz@infradead.org> To: x86@kernel.org, willy@infradead.org, torvalds@linux-foundation.org, akpm@linux-foundation.org Cc: linux-kernel@vger.kernel.org, peterz@infradead.org, linux-mm@kvack.org, aarcange@redhat.com, kirill.shutemov@linux.intel.com, jroedel@suse.de, ubizjak@gmail.com Subject: [PATCH 09/13] x86/mm/pae: Use WRITE_ONCE() References: <20221022111403.531902164@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_NONE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1747388527117400006?= X-GMAIL-MSGID: =?utf-8?q?1747388527117400006?= |
Series |
Clean up pmd_get_atomic() and i386-PAE
|
|
Commit Message
Peter Zijlstra
Oct. 22, 2022, 11:14 a.m. UTC
Disallow write-tearing, that would be really unfortunate.
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
---
arch/x86/include/asm/pgtable-3level.h | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
Comments
On Sat, Oct 22, 2022 at 4:48 AM Peter Zijlstra <peterz@infradead.org> wrote: > > static inline void native_set_pte(pte_t *ptep, pte_t pte) > { > - ptep->pte_high = pte.pte_high; > + WRITE_ONCE(ptep->pte_high, pte.pte_high); > smp_wmb(); > - ptep->pte_low = pte.pte_low; > + WRITE_ONCE(ptep->pte_low, pte.pte_low); With this, the smp_wmb() should just go away too. It was really only ever there as a compiler barrier. Two WRITE_ONCE() statements are inherently ordered for the compiler (due to volatile rules), and x86 doesn't re-order writes. It's not a big deal, since smp_wmb() is just a barrier() on x86-64 anyway, but it might make some improvement to code generation to remove it, and the smp_wmb() really isn't adding anything. If somebody likes the smp_wmb() as a comment, I think it would be better to actually _make_ it a comment, and have these functions turn into just /* Force ordered word-sized writes, set low word with present bit last */ static inline void native_set_pte(pte_t *ptep, pte_t pte) { WRITE_ONCE(ptep->pte_high, pte.pte_high); WRITE_ONCE(ptep->pte_low, pte.pte_low); } or similar. I think that kind of one-liner comment is much more informative than a "smp_wmb()". Or do we already have a comment elsewhere about why the ordering is important (and how *clearing* clears the low word with the present bit first, but setting a *new* entry sets the high word first so that the 64-bit entry is complete when the present bit is set?) Linus
On Sat, Oct 22, 2022 at 10:42:52AM -0700, Linus Torvalds wrote: > On Sat, Oct 22, 2022 at 4:48 AM Peter Zijlstra <peterz@infradead.org> wrote: > > > > static inline void native_set_pte(pte_t *ptep, pte_t pte) > > { > > - ptep->pte_high = pte.pte_high; > > + WRITE_ONCE(ptep->pte_high, pte.pte_high); > > smp_wmb(); > > - ptep->pte_low = pte.pte_low; > > + WRITE_ONCE(ptep->pte_low, pte.pte_low); > > With this, the smp_wmb() should just go away too. It was really only > ever there as a compiler barrier. Right, however I find it easier to reason about this with the smp_wmb() there, esp. since the counterpart is in generic code and (must) carries those smp_rmb()s. Still, I can take them out if you prefer. > Or do we already have a comment elsewhere about why the ordering is > important (and how *clearing* clears the low word with the present bit > first, but setting a *new* entry sets the high word first so that the > 64-bit entry is complete when the present bit is set?) There's a comment in include/linux/pgtable.h near ptep_get_lockless(). Now; I've been on the fence about making those READ_ONCE(), I think KCSAN would want that, but I think the code is correct without them, even if the loads get torn, we rely on the equality of the first and third load and the barriers then guarantee the second load is coherent. OTOH, if the stores (this patch) go funny and get torn bad things can happen, imagine it writing the byte with the present bit in first and then the other bytes (because the compile is an evil bastard and wants a giggle).
--- a/arch/x86/include/asm/pgtable-3level.h +++ b/arch/x86/include/asm/pgtable-3level.h @@ -27,9 +27,9 @@ */ static inline void native_set_pte(pte_t *ptep, pte_t pte) { - ptep->pte_high = pte.pte_high; + WRITE_ONCE(ptep->pte_high, pte.pte_high); smp_wmb(); - ptep->pte_low = pte.pte_low; + WRITE_ONCE(ptep->pte_low, pte.pte_low); } static inline void native_set_pte_atomic(pte_t *ptep, pte_t pte) @@ -58,16 +58,16 @@ static inline void native_set_pud(pud_t static inline void native_pte_clear(struct mm_struct *mm, unsigned long addr, pte_t *ptep) { - ptep->pte_low = 0; + WRITE_ONCE(ptep->pte_low, 0); smp_wmb(); - ptep->pte_high = 0; + WRITE_ONCE(ptep->pte_high, 0); } static inline void native_pmd_clear(pmd_t *pmdp) { - pmdp->pmd_low = 0; + WRITE_ONCE(pmdp->pmd_low, 0); smp_wmb(); - pmdp->pmd_high = 0; + WRITE_ONCE(pmdp->pmd_high, 0); } static inline void native_pud_clear(pud_t *pudp)