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 C60C3C433F5 for ; Sun, 22 May 2022 03:56:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0359E8D000C; Sat, 21 May 2022 23:56:58 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id F27C48D0003; Sat, 21 May 2022 23:56:57 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E171F8D000C; Sat, 21 May 2022 23:56:57 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id CE5048D0003 for ; Sat, 21 May 2022 23:56:57 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id A04E534174 for ; Sun, 22 May 2022 03:56:57 +0000 (UTC) X-FDA: 79492018074.12.BCB7EE5 Received: from mail-il1-f181.google.com (mail-il1-f181.google.com [209.85.166.181]) by imf28.hostedemail.com (Postfix) with ESMTP id 9CD78C000B for ; Sun, 22 May 2022 03:56:27 +0000 (UTC) Received: by mail-il1-f181.google.com with SMTP id e9so3359166ilq.6 for ; Sat, 21 May 2022 20:56:56 -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=WD+OIKZpSTJyD5Vd4IIbMe/iBHfwL25mMqv6khTOaQc=; b=pfN4pPEeY9LYegHJheV6brjF5IhI9WGaVam03hHJvQ45QTGNF+vrM2IC9RhsClS8oP ixAPLv0NJgoRuoPloqF+4j55f1fEuVVWQv46D8DXTahs0bftZvpWZOcK3d7yQXpT5kC0 rtDRcDPi7xUQH3EtXLkKYnOHKilzRci6W66tPcPffgtxHt8OX+HN5Q0r6sTeff0bqHLQ TfXca2REfKX9shwxKV5KIRbBb8k/hKBjF54qBxwdfS7cxmqUGVHvL5/yg5GZ2crvVNoD oVYrRiqiAd4lEptLPKaHNa9rg4M+4LsLKIIuGlj724HV2fOUd8iUhPtNnAj3Jju8QHrK RYpg== 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=WD+OIKZpSTJyD5Vd4IIbMe/iBHfwL25mMqv6khTOaQc=; b=RuP7+POxxTl88MzZDmLFbsqz011rojyJJ7Zl29rfGFzdrP5UpsBhM/sKzHByscYAi/ ahecm0ofouZYRtco9V2rRh5lzQg/rFEv5wuylh22IMW0tTSuVcNdyk83EPNgyxtvQHZz S4ng5dQjwm7IGzsd0xevnNBiGiR8wAMjlyJtXqL5mJG3weUo8hanw3cL4XyE2tysz+eX 9fqz7lyTKwja+AP0Ffmn5af2lD0Ycm3f4MXwmCS2UZixclXkVzVQs77HklTuDqvIdiU5 0s6mOfalmMquxICqgSaGibmOh2U/k5SsZlkF+tkE4a2bmulETilUBe/O3GG2w6KmSBS7 wo6g== X-Gm-Message-State: AOAM533l9oyrGrLeWb8rxvSlQ1YB0DH6PdUC/z9l7rhXvPghC6vFmhFj ogLh2Ku/VAV2vNjvbYGrrQs= X-Google-Smtp-Source: ABdhPJyRBpAs9QXdK3UcexEhJHfxO8KKO3LQ830mo1fzt+XW+RBn5su2d0kvUMJS6s/h202Aygl5Dg== X-Received: by 2002:a05:6e02:1c87:b0:2cf:2d3d:dd89 with SMTP id w7-20020a056e021c8700b002cf2d3ddd89mr9182543ill.36.1653191816560; Sat, 21 May 2022 20:56:56 -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 b101-20020a0295ee000000b0032e13e37940sm1806124jai.140.2022.05.21.20.56.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 21 May 2022 20:56:55 -0700 (PDT) Date: Sun, 22 May 2022 03:56:54 +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: 9CD78C000B X-Stat-Signature: m735oeoeqrkf3j1k6fe5xwyx3mpd4wff Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=pfN4pPEe; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf28.hostedemail.com: domain of 42.hyeyoo@gmail.com designates 209.85.166.181 as permitted sender) smtp.mailfrom=42.hyeyoo@gmail.com X-Rspam-User: X-Rspamd-Server: rspam06 X-HE-Tag: 1653191787-542800 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. > Sounds reasonable. Better explicit than implicit. > 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. Yeah that would be a bit more explicit solution. > 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. Simply adding dump_stack() tells me my kernel on my machine does not use set_memory.c for userspace mappings but Hmm I'll take a look. > 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. Thanks for that information! Thanks, Hyeonggon