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 D11C1C48260 for ; Tue, 13 Feb 2024 12:06:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6816E6B0085; Tue, 13 Feb 2024 07:06:31 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 631996B0087; Tue, 13 Feb 2024 07:06:31 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4F9066B0088; Tue, 13 Feb 2024 07:06:31 -0500 (EST) 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 3F3126B0085 for ; Tue, 13 Feb 2024 07:06:31 -0500 (EST) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id C791E80B79 for ; Tue, 13 Feb 2024 12:06:30 +0000 (UTC) X-FDA: 81786653340.01.53A75B8 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf26.hostedemail.com (Postfix) with ESMTP id E4F67140010 for ; Tue, 13 Feb 2024 12:06:28 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=none; spf=pass (imf26.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com; dmarc=pass (policy=none) header.from=arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1707825989; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=67eaQEOT4mmF6ICIirmAMig0hFRsZ88l6CFRpOT/Qf0=; b=ocVqy0ZvX1R4e5o3uZmKpjL3MHhKwdoXV4HHHwzftAUbBe++qdlcvovtjdMeZfYiQiMMFY lsVH3Z3Pe8d3A8fty8Y/2RgeXfNvpcbSy69YkiJYQXCF4jFCGOS1k779FTfZwhgS+nQpgG XRg7pwg25ybyofPwwKgRTi3ubUH+KAE= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1707825989; a=rsa-sha256; cv=none; b=5w19X3Aieuz9wTnwURUxLOOy9R0X4vOt1+FKTKJkaCAGJdycmXZuy0jsTB6Uz9X4AGZ8t9 vzD2YAKBxIr5nHyLEbmsISP9KHYr8bfMd3kHOyvB3gHNaENf4irdraGVnmpxq5CXcgDpJ1 0lO8L1sj3acrSL+7LeWd85Q2cOj7z3A= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=none; spf=pass (imf26.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com; dmarc=pass (policy=none) header.from=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id D0175DA7; Tue, 13 Feb 2024 04:07:08 -0800 (PST) Received: from [10.1.36.184] (XHFQ2J9959.cambridge.arm.com [10.1.36.184]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 0803A3F762; Tue, 13 Feb 2024 04:06:23 -0800 (PST) Message-ID: Date: Tue, 13 Feb 2024 12:06:22 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 19/25] arm64/mm: Wire up PTE_CONT for user mappings Content-Language: en-GB From: Ryan Roberts To: Mark Rutland Cc: Catalin Marinas , Will Deacon , Ard Biesheuvel , Marc Zyngier , James Morse , Andrey Ryabinin , Andrew Morton , Matthew Wilcox , David Hildenbrand , Kefeng Wang , John Hubbard , Zi Yan , Barry Song <21cnbao@gmail.com>, Alistair Popple , Yang Shi , Nicholas Piggin , Christophe Leroy , "Aneesh Kumar K.V" , "Naveen N. Rao" , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , linux-arm-kernel@lists.infradead.org, x86@kernel.org, linuxppc-dev@lists.ozlabs.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <20240202080756.1453939-1-ryan.roberts@arm.com> <20240202080756.1453939-20-ryan.roberts@arm.com> <64395ae4-3a7d-45dd-8f1d-ea6b232829c5@arm.com> In-Reply-To: <64395ae4-3a7d-45dd-8f1d-ea6b232829c5@arm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: E4F67140010 X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: wiestpktzj8y4yfwe4qk94ece9r86yqh X-HE-Tag: 1707825988-495513 X-HE-Meta: U2FsdGVkX1/dTdA2Pb9qw6LjcTJr+pPs7ztkCoTx/GIczmWs7pzHPsF0BDwxizz1hvU6POe7YUZgJUeBd6RARjOSNMB1zPBvS+sGOG8xPF+6UFu2TEuxQv3e8lNWp5aw61d7nwEu9f/XOcQw3gmAoSjhUiJMq2J6MkZpNc7w5xZ0nN28H+YqG4/uJK39ioeoVaAzYAViH2HMZiWeooDs8DidNBXDtMMCQ7zzWv65G40hXzpLN6HbsO0iWQvVrgr6NffMF2nl5aXjPPHqN8TaRPXgaBtBj0pcfw2a3guWpmJ2woHe7Bb3HKNct/Hc7HiGQWjm6xfuQmXuNGY7zfnPXTF3oMnit0wgqm5AtmMd68T2tBNLPnXqpSZs3Lwmm8Vn+wkMrLwplwWkPaoaygdtEpim+BHGzVgVDw56d9y1CBhKiFnCm7xvlvpoHVkCVw5XUFEt0eyvqaE0YV9brgOZ6Pt45Uhwe1gRp7WFDYFm0jOwdSk2/ft9ixxcVad/aeviyKD3YyXhPPtSyPCgZjcU/TV9QL+Jz0TYZ0wrVI+y6LXwSEacer/WK2LwW6QinMFlkUwyySa0a2owxNTPXxgRT2ANPYWfpJiLdGyUZJJlrZ+krc4l/hM+89c1xIOJhHCXIf47oNozzyUawn8fF70IdPGRkT8yoSnJcBRygxiwiU6XPc2oE/AcLHUyLT/zdXJKSZ/IM2n5K1Xky/L0P3YNgLugzhMzxHTSpBIDAkxz4KogRKBaQemKJA/MZHf7MgdKGNyUVD7LsaHHtUeJR6agNXPuuDAhhaQk6ntNnGeU1Li59/37xurnd0100yWvcvcIbYO7GEyH5SHHeWDrr26mhCXGxZAzdWHzrmSH+i6OYdlb+L635gqzCQlPvNIwTH4PSqHjnKlS7SL7qAxd8kCEOJbMajtzFnJu/oCBjASZLLKopBKYhU8FIG6zSlq+ycq4vGjvXM/AH0XqnjR7L1/ hy89m6e3 qOCtppZ8cDZTC2HVRQsm9+Dim36UedTfyhndCcwYjIvRQbHsTtJz27CrOaSChUV4UY2KztxIXYWcHD1dMlfHp6hw+1pIqQOZk3mU5uSO8QFpj8SaHokl8IiVjdNa84lSk6fe+aB7YR7D0Hv1WOqFE6+aYes2RIvvUdDH3eck3qW3pvN1zLImsp3ljB7I79QGZ+WGssxK7mPUw8ZFwP39JkRbsXRZOVMRCrm3cSazGXMwjFn220i4LWySa3ofb2kEiPZTZJbDelAt89HBhj3OGS+rkC1rBnFT1iyju 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: List-Subscribe: List-Unsubscribe: On 12/02/2024 20:38, Ryan Roberts wrote: > [...] > >>>>> +static inline bool mm_is_user(struct mm_struct *mm) >>>>> +{ >>>>> + /* >>>>> + * Don't attempt to apply the contig bit to kernel mappings, because >>>>> + * dynamically adding/removing the contig bit can cause page faults. >>>>> + * These racing faults are ok for user space, since they get serialized >>>>> + * on the PTL. But kernel mappings can't tolerate faults. >>>>> + */ >>>>> + return mm != &init_mm; >>>>> +} >>>> >>>> We also have the efi_mm as a non-user mm, though I don't think we manipulate >>>> that while it is live, and I'm not sure if that needs any special handling. >>> >>> Well we never need this function in the hot (order-0 folio) path, so I think I >>> could add a check for efi_mm here with performance implication. It's probably >>> safest to explicitly exclude it? What do you think? >> >> Oops: This should have read "I think I could add a check for efi_mm here >> *without* performance implication" > > It turns out that efi_mm is only defined when CONFIG_EFI is enabled. I can do this: > > return mm != &init_mm && (!IS_ENABLED(CONFIG_EFI) || mm != &efi_mm); > > Is that acceptable? This is my preference, but nothing else outside of efi > references this symbol currently. > > Or perhaps I can convince myself that its safe to treat efi_mm like userspace. > There are a couple of things that need to be garanteed for it to be safe: > > - The PFNs of present ptes either need to have an associated struct page or > need to have the PTE_SPECIAL bit set (either pte_mkspecial() or > pte_mkdevmap()) > > - Live mappings must either be static (no changes that could cause fold/unfold > while live) or the system must be able to tolerate a temporary fault > > Mark suggests efi_mm is not manipulated while live, so that meets the latter > requirement, but I'm not sure about the former? I've gone through all the efi code, and conclude that, as Mark suggests, the mappings are indeed static. And additionally, the ptes are populated using only the _private_ ptep API, so there is no issue here. As just discussed with Mark, my prefereence is to not make any changes to code, and just add a comment describing why efi_mm is safe. Details: * Registered with ptdump * ptep_get_lockless() * efi_create_mapping -> create_pgd_mapping … -> init_pte: * __ptep_get() * __set_pte() * efi_memattr_apply_permissions -> efi_set_mapping_permissions … -> set_permissions * __ptep_get() * __set_pte() Thanks, Ryan > > Thanks, > Ryan >