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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 204D4C433EF for ; Sun, 29 May 2022 10:32:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 153728D0002; Sun, 29 May 2022 06:32:42 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 103338D0001; Sun, 29 May 2022 06:32:42 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EE32E8D0002; Sun, 29 May 2022 06:32:41 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id DBBDC8D0001 for ; Sun, 29 May 2022 06:32:41 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 9D44132BA0 for ; Sun, 29 May 2022 10:32:41 +0000 (UTC) X-FDA: 79518416922.06.A3A7138 Received: from mail-io1-f49.google.com (mail-io1-f49.google.com [209.85.166.49]) by imf20.hostedemail.com (Postfix) with ESMTP id 4C2E91C004F for ; Sun, 29 May 2022 10:32:24 +0000 (UTC) Received: by mail-io1-f49.google.com with SMTP id p74so8818747iod.8 for ; Sun, 29 May 2022 03:32:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=LwwoQYR2ORpRNhK4MoMYiNzHU8QyLU3W9ubNdWH2aeo=; b=MVeQo4cZ/E0x6L7YEyK/+zDWpm10pgfLFBacjunWcD8PSlL2po4SV7xzR8nUnm2Rc3 h6Rm2PGjwh90MOQdyF1hzO+WKvAhOZTIAB9AaHiYiZX/VTMUnnvNRYv02nicDGgVRzA8 cwZXJkLTilVXb9401oQ1eT1bZswmIv8F/BySHzJsW+GGZD+nzqzN1pxMmSNoNlDfLB77 ZSSXEJfXwBWbu3NTsROTFq8OoDab3eI85PICiNyAesF4e3rWVYtcHf0oTmg5vR0aqQnw pTYvD/aaIOmw5W13u+vg5VgEkMUCdAN3ogIbk+5GOxDjPEo6hPSBaFyOltb0AGbbnLR7 MCMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=LwwoQYR2ORpRNhK4MoMYiNzHU8QyLU3W9ubNdWH2aeo=; b=PQ9wtfwF/j6PTtsK7OD5II0gdtW4q5hkfpOZkKYGMprb9r6XenkSljv0dW/4peyPm4 2tTlhNAask+K8nooCwO3pZxKcDBbBIIdxi42SQKVBsa2SiBXxFrW+rZEWDnb4L2ig8yd JjJ2N4QdRZpuWGGocGoGN6NmrOBLaUA595siQoBEOyRQuiN4MdCx7Eme4D5b+LTDuk9i uf1pWxVvFu+7MIgLCHO0RH0wXADWvUjAEHk114P8hGOKKJvEvbPgV/b2MnRe9NIROBIV t9gaFIkZBmJII9OpezZaRr8Id058Fm83Gx/r8bEj/QwKy+KkmqJUeyTdroowFux0ietv XbRw== X-Gm-Message-State: AOAM533nkPs/KMB3dzrs3jq1JfGnB4D7VEot+kTiCifYjyTEwnYWJi2B 7q54+ImiC1eDWiT6mTIwgNg= X-Google-Smtp-Source: ABdhPJwPhNG/9jG22wHXfc3SUixEmr9mAtpCKn02IlcEatGkfhRZMQCgqgap3G57mZ2FECfYJcOR4w== X-Received: by 2002:a05:6638:2601:b0:331:3a3:3bd8 with SMTP id m1-20020a056638260100b0033103a33bd8mr3546750jat.62.1653820360416; Sun, 29 May 2022 03:32:40 -0700 (PDT) Received: from n2.us-central1-a.c.spheric-algebra-350919.internal (151.16.70.34.bc.googleusercontent.com. [34.70.16.151]) by smtp.gmail.com with ESMTPSA id x18-20020a927c12000000b002d149ec2606sm2794127ilc.65.2022.05.29.03.32.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 29 May 2022 03:32:39 -0700 (PDT) Date: Sun, 29 May 2022 10:32:37 +0000 From: Hyeonggon Yoo <42.hyeyoo@gmail.com> To: Dave Hansen Cc: Mel Gorman , Tom Lendacky , Rick Edgecombe , Dave Hansen , Andy Lutomirski , Peter Zijlstra , Thomas Gleixner , Ingo Molnar , Borislav Petkov , x86@kernel.org, "H. Peter Anvin" , "Kirill A. Shutemov" , Tianyu Lan , "Aneesh Kumar K.V" , linux-kernel@vger.kernel.org, linux-mm@kvack.org, vbabka@suse.cz, akpm@linux-foundation.org, willy@infradead.org Subject: Re: Is _PAGE_PROTNONE set only for user mappings? Message-ID: References: <20220506051940.156952-1-42.hyeyoo@gmail.com> <56f89895-601e-44c9-bda4-5fae6782e27e@amd.com> <5fe161cb-6c55-6c4d-c208-16c77e115d3f@amd.com> <8c2735ac-0335-6e2a-8341-8266d5d13c30@intel.com> <20220512103748.GH3441@techsingularity.net> <3f2f7c09-ddf3-6052-9860-8554a4ff2798@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3f2f7c09-ddf3-6052-9860-8554a4ff2798@intel.com> X-Rspamd-Queue-Id: 4C2E91C004F X-Stat-Signature: gik1xgpja958gi4ttk3bgps75ykj4bbq Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=MVeQo4cZ; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf20.hostedemail.com: domain of 42.hyeyoo@gmail.com designates 209.85.166.49 as permitted sender) smtp.mailfrom=42.hyeyoo@gmail.com X-Rspam-User: X-Rspamd-Server: rspam11 X-HE-Tag: 1653820344-803361 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon, May 16, 2022 at 07:04:32AM -0700, Dave Hansen wrote: > On 5/12/22 22:33, Hyeonggon Yoo wrote: > > Thanks Mel, and IIUC nor does do_kern_addr_fault() in arch/x86/mm/fault.c > > expect _PAGE_PROTNONE instead of _PAGE_GLOBAL. I want to make it clear > > in the code that _PAGE_PROTNONE is only used for user mappings. > > > > How does below look? > > > > diff --git a/arch/x86/include/asm/pgtable_types.h b/arch/x86/include/asm/pgtable_types.h > > index 40497a9020c6..f8d02b91a90c 100644 > > --- a/arch/x86/include/asm/pgtable_types.h > > +++ b/arch/x86/include/asm/pgtable_types.h > > @@ -35,7 +35,10 @@ > > #define _PAGE_BIT_DEVMAP _PAGE_BIT_SOFTW4 > > > > /* If _PAGE_BIT_PRESENT is clear, we use these: */ > > -/* - if the user mapped it with PROT_NONE; pte_present gives true */ > > +/* > > + * if the user mapped it with PROT_NONE; pte_present gives true > > + * this is only used for user mappings (with _PAGE_BIT_USER) > > + */ > > #define _PAGE_BIT_PROTNONE _PAGE_BIT_GLOBAL > > > > #define _PAGE_PRESENT (_AT(pteval_t, 1) << _PAGE_BIT_PRESENT) > > @@ -115,7 +118,8 @@ > > #define _PAGE_DEVMAP (_AT(pteval_t, 0)) > > #endif > > > > -#define _PAGE_PROTNONE (_AT(pteval_t, 1) << _PAGE_BIT_PROTNONE) > > +#define _PAGE_PROTNONE ((_AT(pteval_t, 1) << _PAGE_BIT_USER) | \ > > + (_AT(pteval_t, 1) << _PAGE_BIT_PROTNONE)) > > > > /* > > * Set of bits not changed in pte_modify. The pte's > > I don't like the idea of _PAGE_BIT_USER being so implicit. It is > something kernel users should know explicitly that they are messing with. > > I was thinking of something more along the lines of taking the > set_memory.c code and ensuring that it never sets (or even observes) > _PAGE_BIT_GLOBAL on a _PAGE_USER mapping. There was also a question of > if set_memory.c is ever used on userspace mappings. It would be good to > validate whether it's possible in-tree today and if not, enforce that > _PAGE_USER PTEs should never even be observed with set_memory.c. Writing code I'm a bit confused: commit d1440b23c922d8 ("x86/mm: Factor out pageattr _PAGE_GLOBAL setting") says: "This unconditional setting of _PAGE_GLOBAL is a problem when we have PTI and non-PTI and we want some areas to have _PAGE_GLOBAL and some not." Is this this sentence not valid anymore in PTI, and just unconditionally setting _PAGE_GLOBAL would be okay in kernel side regardless of PTI? I'm wondering it because previously I thought "Let's not clear _PAGE_GLOBAL in set_memory.c for kernel mappings and make pmd/pte_present() not confuse when _PAGE_USER is not set" But you don't like it as it's a bit implicit. Then I wonder - how do we know when to set _PAGE_GLOBAL again? > The arch/x86/mm/dump_pagetables.c code is also a reasonable place to put > assumptions about the page tables since it walks *everything* when asked.