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 lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 97E9CC4829A for ; Tue, 13 Feb 2024 12:07:25 +0000 (UTC) Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4TZ0SX1hTnz3vX1 for ; Tue, 13 Feb 2024 23:07:24 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=arm.com (client-ip=217.140.110.172; helo=foss.arm.com; envelope-from=ryan.roberts@arm.com; receiver=lists.ozlabs.org) Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lists.ozlabs.org (Postfix) with ESMTP id 4TZ0S35MD0z3blb for ; Tue, 13 Feb 2024 23:06:58 +1100 (AEDT) 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 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-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Kefeng Wang , x86@kernel.org, David Hildenbrand , Catalin Marinas , Yang Shi , Dave Hansen , linux-mm@kvack.org, Andrey Ryabinin , "H. Peter Anvin" , Will Deacon , Ard Biesheuvel , Marc Zyngier , Alistair Popple , Barry Song <21cnbao@gmail.com>, Matthew Wilcox , "Aneesh Kumar K.V" , Ingo Molnar , Zi Yan , "Naveen N. Rao" , John Hubbard , Nicholas Piggin , Borislav Petkov , Thomas Gleixner , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, James Morse , Andrew Morton , linuxppc-dev@lists.ozlabs.org Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" 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 >