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 C6428CE7B18 for ; Fri, 6 Sep 2024 13:45:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5A1426B0089; Fri, 6 Sep 2024 09:45:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 550FA6B008A; Fri, 6 Sep 2024 09:45:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 440376B008C; Fri, 6 Sep 2024 09:45:45 -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 25F2A6B0089 for ; Fri, 6 Sep 2024 09:45:45 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id A8FAA161956 for ; Fri, 6 Sep 2024 13:45:44 +0000 (UTC) X-FDA: 82534436208.10.210D17A Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf29.hostedemail.com (Postfix) with ESMTP id 16863120015 for ; Fri, 6 Sep 2024 13:45:41 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=none; spf=pass (imf29.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=1725630293; 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=5LY4uAgRpMhuYNOADC2pfcp2aL9rxLMn87xmDUl1QMc=; b=qUw7Tu0RpbelTQBDNeu1TOLEtH/S1ALRLb+lJEacwV5NyGZMrmHHTS0rE72naNP6AmV8aQ 42tQoIXovs9HoLFgMDvlT30F9qMWLLnjPJl6p4VfIdhvdIucRrGJCTyrdLrWju5mdRFY8g 708gFb0QE0N4g2vMFYXhgNccuvw5ZDo= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=none; spf=pass (imf29.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-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1725630293; a=rsa-sha256; cv=none; b=YQWydzCTo0KVKRyfElcUANvAULYr+JQ8lz588wc5Bru4oSQ+u8ENUbJxQwHyg+BHUaaAK5 gQoB+7qa/o3ZmQEOklZm8ysY+n5w+TRyshJUk4UlsJ7/2E9YKqO+pJgE7JHbVv2TCvhKm5 8PkAHjEUX1ZWBfUHZpQ7BSZQfmFrhK0= 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 47E21FEC; Fri, 6 Sep 2024 06:46:08 -0700 (PDT) Received: from [10.57.86.132] (unknown [10.57.86.132]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 0DFA53F73B; Fri, 6 Sep 2024 06:45:39 -0700 (PDT) Message-ID: <16b02b7e-7877-4965-b15a-bf3b600134f7@arm.com> Date: Fri, 6 Sep 2024 14:45:38 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] mm/vmalloc:arm64 support cont-pte huge vmalloc mapping Content-Language: en-GB To: Haiwang Fu , akpm@linux-foundation.org, mark.rutland@arm.com, catalin.marinas@arm.com, will@kernel.org Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org References: <20240906130919.3765401-1-fuhaiwang@bytedance.com> From: Ryan Roberts In-Reply-To: <20240906130919.3765401-1-fuhaiwang@bytedance.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam03 X-Rspam-User: X-Rspamd-Queue-Id: 16863120015 X-Stat-Signature: zu4cknwb5k59b3b93mxxez5qp4uyh3c1 X-HE-Tag: 1725630341-214328 X-HE-Meta: U2FsdGVkX1/J4gTbhHafBRDIR0Vi8GZ/m+P55iBnQimh10Sf2UOJkSB9h5sA0TJf4EBgRCMr9XSm/OR+JpB50VSMlU7QIy0sm9496I6ggBm13e/c2khJjy3HEezODNQ+a+fVFjv4Sf8XBqwxQyEf5C6IfK/g8sRzE58c7Bg7pQMcKg7up1ZVknn8wAo3xr4rw+Jf9Jmn+xM70LOid62jC86AlYCHD9F/bpACnfIJNKSFpJNXOYOTmm012c9TQR42YIxV2mF7bAqvZl1LLiI1wAm1bkQNCTg1n9/JKAddcMydC+79eaL0irT4m0vk/eJHnkolW5Hq7SlWYY5fToUkOr6NT6/0Z4eO9nIke0thoc1LmE8mTL3kvE0k3V6n77Jv03qvJuThv1T2mS8OyCod+ntFh5QNf9YsXtgp+fVHg/JFCcUp8PUf/P6mZv5kb/VSdXZVnayeELKA5Oub/gxHG1cbIS9JB8UxEFoDb16LXHT9IJYZkuhA/juKLTUb4KCRGqwN+WMuBRUgDd5VmVRQ6LJpFweycsu0nK1HjlA87wvffCGbiyNuO9j4IovlIjTSkHFFNe/wEyfgp1FvE6m6i+nx3mvOcbF6iv8d277R/2Ayo6o5g/iET8J+Ia0ZzLsofitPoV7y1CKPTqzzHW9ysUxrkkhvpm2UPiYPgRJ8cXqZhlo0D9O6CvYydFzeOgON0qjaFRWGfSCvB+F7OznTatnvmDk4Dm/r7K7VAoBHwbqBZzRplh2wUy3u/hcAClLueg+Sx3TcxW1xypDNfjJBGDxUiMFRhMvbTa/3wwii3TRI0nkoSfaBO2pfIAb2zOlmTNVLX9dJJgeC09iHdYtXZs7D0d0VcdkxCt/+h3xSxM0kMk4Ca43GYcLAduPpXPsr9t43tYQpFCkOLrQkRW5N2BHkYQjK+gMZ87kU5sZ9Qf/dK/u0c/6S0SWQBOJ1t3RcN8Ool5TdKzcu3A+/m5n MEdMSrCN DlIT9uEANOPuu6hMRBZ6eP1lcH+Ik2FM1I+DfDwE8INtDLmbo+s1RaXyFh79LHfzc7x/gcHMVdLIdKsbNfcNCWd4JmA1o/HllJYDjwAPMcQkLIHTet2OXfWSJXGKKsuBSILIX8ODflVmu051zw2nHPcCaZkSFJkPPnY+jgEUVquryrNhH+MBX3KVliI6VPmdaHzaQdzqZ8q1OJbNWfpNyR1hM5hcptcMo1Eeb+uHVbd39UNhhOMyBxw1vpwe7Wajrsi2FVrWjqsUDrDhYmCpTp4b+obyrZSVMrxFEX6DG3++C+qunbA56R66KeIKtf+uf4q79 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 06/09/2024 14:09, Haiwang Fu wrote: > From: fuhaiwang > > Arm64 support contiguous bit which is used to increase the mapping size > at the pmd and pte level. > > Now huge vmalloc support PMD and PTE level mapping, and support > multi size at pte level. > > arm64: implement the fllowing interface on arm64 to support > cont-pte huge vmalloc mapping. > arch_vmap_pte_supported_shift(*) > arch_vmap_pte_range_map_size(*) I believe that riscv tried to do the same thing and had to revert it because its possible to unmap a portion of what was allocated and there was no easy way to fix up the mapping safely. See [1]. I believe arm64 might suffer from a similar problem; I'm guessing the contpte code would attempt to repaint the ptes with/out the PTE_CONT bit, as needed. But that isn't safe on kernel mappings because there is no way to recover if another thread tries to access the mapping concurrently. The code is only safe for user mappings where the racing fault will get serialized behind the PTL. [1] https://lore.kernel.org/linux-riscv/20240227205016.121901-2- alexghiti@rivosinc.com/ Thanks, Ryan > > Signed-off-by: fuhaiwang > --- > arch/arm64/include/asm/pgtable.h | 28 ++++++++++++++++++++++++++++ > 1 file changed, 28 insertions(+) > > diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h > index c329ea061dc9..3f32e3150680 100644 > --- a/arch/arm64/include/asm/pgtable.h > +++ b/arch/arm64/include/asm/pgtable.h > @@ -1814,6 +1814,34 @@ static inline void clear_young_dirty_ptes(struct vm_area_struct *vma, > > #endif /* CONFIG_ARM64_CONTPTE */ > > +static inline unsigned long arch_vmap_pte_range_map_size(unsigned long addr, unsigned long end, > + u64 pfn, unsigned int max_page_shift) > +{ > + if (end - addr < CONT_PTE_SIZE) > + return PAGE_SIZE; > + > + if ((1UL << max_page_shift) < CONT_PTE_SIZE) > + return PAGE_SIZE; > + > + if (!IS_ALIGNED(addr, CONT_PTE_SIZE)) > + return PAGE_SIZE; > + > + if (!IS_ALIGNED(PFN_PHYS(pfn), CONT_PTE_SIZE)) > + return PAGE_SIZE; > + > + return CONT_PTE_SIZE; > +} > +#define arch_vmap_pte_range_map_size arch_vmap_pte_range_map_size > + > +static inline int arch_vmap_pte_supported_shift(unsigned long size) > +{ > + if (size >= CONT_PTE_SIZE) > + return CONT_PTE_SHIFT; > + else > + return PAGE_SHIFT; > +} > +#define arch_vmap_pte_supported_shift arch_vmap_pte_supported_shift > + > #endif /* !__ASSEMBLY__ */ > > #endif /* __ASM_PGTABLE_H */