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 2631EC433F5 for ; Mon, 16 May 2022 14:05:02 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 600E36B0071; Mon, 16 May 2022 10:05:02 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5B0DC6B0072; Mon, 16 May 2022 10:05:02 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 451426B0073; Mon, 16 May 2022 10:05:02 -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 36B176B0071 for ; Mon, 16 May 2022 10:05:02 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 0C3E921ABB for ; Mon, 16 May 2022 14:05:02 +0000 (UTC) X-FDA: 79471777644.23.1973C4A Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by imf28.hostedemail.com (Postfix) with ESMTP id 8F527C00BC for ; Mon, 16 May 2022 14:04:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1652709901; x=1684245901; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=xfUbkQZw0S92oKI8y36PgkSXoImP8mak437/D1fQZ04=; b=QlD0ub29vvLIydVFgnyTJNJS0NMSZmWpOKpg67XktqRRp9VwKxBheO1b 20uhvMy2Ctve4B3ovwLBgxzNIbDjClWUvEIz2zSnl/k2MoF8Gtu1WDRth KhwuLSyyWvjMNmy4Kb9FnhmSNM/pC70ny6rCRTTb7PHhnhl7k2sOBSCG+ b/0+OKJ8Lr6SOHeizrAz8jUjYF1gbxGM6K2Ru1g9f0oCMC9UOgUQ1CULx qDX8KtKSy6aYXYT72EBwj+WFNO1RDW0aHr0sWxBb0f0XVhylXDn25ILN6 Nh0SAjFJ8uB52KumzUA+/oQjmb7DWe6FPvriDFYCDnULFUijNPo21S2zI Q==; X-IronPort-AV: E=McAfee;i="6400,9594,10348"; a="269666791" X-IronPort-AV: E=Sophos;i="5.91,230,1647327600"; d="scan'208";a="269666791" Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 May 2022 07:04:34 -0700 X-IronPort-AV: E=Sophos;i="5.91,230,1647327600"; d="scan'208";a="555263415" Received: from dmjacob-mobl.amr.corp.intel.com (HELO [10.212.130.28]) ([10.212.130.28]) by orsmga002-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 May 2022 07:04:33 -0700 Message-ID: <3f2f7c09-ddf3-6052-9860-8554a4ff2798@intel.com> Date: Mon, 16 May 2022 07:04:32 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Subject: Re: Is _PAGE_PROTNONE set only for user mappings? Content-Language: en-US To: Hyeonggon Yoo <42.hyeyoo@gmail.com>, Mel Gorman Cc: 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 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> From: Dave Hansen In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Stat-Signature: 7s5q46quisnzbb3matomm8t9fx5arrqf X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 8F527C00BC X-Rspam-User: Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=QlD0ub29; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf28.hostedemail.com: domain of dave.hansen@intel.com has no SPF policy when checking 192.55.52.120) smtp.mailfrom=dave.hansen@intel.com X-HE-Tag: 1652709876-103290 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 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. 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.