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 EE42EC5B549 for ; Fri, 30 May 2025 10:37:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6EB8E6B00F3; Fri, 30 May 2025 06:37:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 69B916B00F4; Fri, 30 May 2025 06:37:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5B1816B00F5; Fri, 30 May 2025 06:37:45 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 3363D6B00F3 for ; Fri, 30 May 2025 06:37:45 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id C38B858355 for ; Fri, 30 May 2025 10:37:44 +0000 (UTC) X-FDA: 83499223248.19.BF6D1C4 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf14.hostedemail.com (Postfix) with ESMTP id 00B8710000E for ; Fri, 30 May 2025 10:37:42 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=none; spf=pass (imf14.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=1748601463; 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=ULnna/qzT25PI8uV/En4XfLMaIHAgPE+95abAXIgRGY=; b=Z9ogRHUoKwDtavkEnxzwxiKCE6bVGMV+8i2QL65zm3X5bUIUNhQXrkTSR/OTh+6pl2zjBO IMq9aOiRvAfIBhmsAoRpV682NCj3IMVrUyVrOTsrz5amuV1GUjE4NvWoKRWlDhdhAnPIXY jZ3FOXZloLmdS4VqnGMBB9TEDnXay00= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=none; spf=pass (imf14.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=1748601463; a=rsa-sha256; cv=none; b=dZ0HoCE0NXQil6vox2w9vZU1xcEfdHO109CVILFgPr2m7uCRzPikQNo6Fl2VFsWJPuBlzj 8olv5TuQpwunHHU55dD4hB1RkuuupQN9ixPtGV44WjQnAk71LWcPzQd37q0SepizQd9AGF nF7X19qszUZQo3+gqTt7wpTQM5rL24c= 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 B6B8316F2; Fri, 30 May 2025 03:37:25 -0700 (PDT) Received: from [10.57.95.14] (unknown [10.57.95.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 8E0FB3F673; Fri, 30 May 2025 03:37:39 -0700 (PDT) Message-ID: <090440b6-9501-4f29-8b9f-1f6e6f3a6fbc@arm.com> Date: Fri, 30 May 2025 11:37:37 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 0/3] Enable huge-vmalloc permission change Content-Language: en-GB To: Dev Jain , akpm@linux-foundation.org, david@redhat.com, catalin.marinas@arm.com, will@kernel.org Cc: lorenzo.stoakes@oracle.com, Liam.Howlett@oracle.com, vbabka@suse.cz, rppt@kernel.org, surenb@google.com, mhocko@suse.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, suzuki.poulose@arm.com, steven.price@arm.com, gshan@redhat.com, linux-arm-kernel@lists.infradead.org References: <20250530090407.19237-1-dev.jain@arm.com> <381fec11-0e05-4bf0-9cd8-f272fde7558f@arm.com> From: Ryan Roberts In-Reply-To: <381fec11-0e05-4bf0-9cd8-f272fde7558f@arm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 00B8710000E X-Stat-Signature: ut7zehfnwge1ayoacqc4e3yfbpfb9fjz X-Rspam-User: X-Rspamd-Server: rspam04 X-HE-Tag: 1748601462-154163 X-HE-Meta: U2FsdGVkX1+yK+ezC2VUCuXyqfPlF4nC8x2L5I0h3nzVGH9cu6e3sdI6iZkteADGfITYNwyIIPS4YlZEkwhfdfLPMpB5FeAg3HzJ0WdQidyO7vh8b3unjPdvUc8yD1efKruuendC0j7S52C6OiZ3rVDMpvYRNUYQCiwq7Y1k+Es/mIvrnFpn7Sgv8vl3VNZDciWq1htIsUCGn7Doov8ebj9gzcV9EQv9x63dhBitS46i1ACGI8Te4ajZk9U6rqn+qAfS6PXq1xA/9gDrOTOEQ8E3j7cYu/YeCX8aHFgBNVKv7HULOy8tWqkASFGeMBQpoua3E/zO6u/dxQIUqinbWxAM1Gj+UnbIJt4UwT2YlQNkBKPoM0eQ7v8D8UYwfLHCtHI/wF3kCAT5MuBXgoaxDDjHrBRQM6jQ/yZ2YZkRU/9UAXdoXn1cYbPK5T3vEZONOIEFIw7ExWUY5Bf4nK38ugWQjBMENoC7+h16WFS55RQKuf+hRgi4lF8IPiojqIjmVfujrxvCs19Jz2bWFWrQogTTMuIwzY3l3+4HZuYVqZMvv+8rD7fykTqCOJ5tyPXirKLM9ylMY4oZVUBzjgNjf5nM1RRqfvvfBknyWERaRzO/aJiU2NoH4hr4Tri3aJfvgLehf/GKpYO78QchslBU3XR9qD6Yc2kIFanC+PrtLLzA6rEg1hkypvLHKsoFJmdZ+lzD+HtcOkpnnJmw1LL3jwO9CPzOkJoPMSEau9Xl33505POMwLY2bYSzfFxL5zy5GWBYzVeflMtyVKu9o9e/mLmaY4r2OEqSqVumb3oX/splpkCNW4vH5wGhvqQrQfQAvBjNh1ZmSrxEpZWWTAN8sZdm1/lB+qpn4pgEbUwf0up/gZ4XRoX+OLolMOzwIJgzstSI99xfxWzWQXlF46OLf+EdCyj+7d0HPDjoRcNWhpg4PKw6+tOLBwqcyeBOd90Iikizfy8muEFZ2ufWP0b ARheuOMB 2UeGY/9NFBknHnQVBT0hcn5v3QzKUk5lRK0F++oT4+53m/rwdrsW1bGo43zGVqOUVQHO3PuuqvX1xjs4OLn+PQBM1KJDiDiv0NMkoaqO6oyXKpHT6Q3LVyn1PZqMSoBLfJngZPzwkBJz7dW7u7AVI7maOkDIMl6hB5Mw4wDThLcNVeEl0BpJWKTqNuXttlVT64pdOhXC5EbGvN65WEWQTNPprihWDMCRRffl8K7hbXAXTZNDAuYfizOBUumLm0I23ik/M 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 30/05/2025 11:10, Dev Jain wrote: > > On 30/05/25 3:33 pm, Ryan Roberts wrote: >> On 30/05/2025 10:04, Dev Jain wrote: >>> This series paves the path to enable huge mappings in vmalloc space by >>> default on arm64. > For this we must ensure that we can handle any permission >>> games on vmalloc space. >> And the linear map :) >> >>> Currently, __change_memory_common() uses >>> apply_to_page_range() which does not support changing permissions for >>> leaf mappings. >> nit: A "leaf mapping" is the lowest level entry in the page tables for a given >> address - i.e. it maps an address to some actual memory rather than to another >> pgtable. It includes what the Arm ARM calls "page mappings" (PTE level) and >> "block mappings" (PMD/PUD/.. level). apply_to_page_range() does support page >> mappings, so saying it doesn't support leaf mappings is incorrect. It doesn't >> support block mappings. > > Sorry, again got confused by nomenclature : ) > >> >>> We attempt to move away from this by using walk_page_range_novma(), >>> similar to what riscv does right now; however, it is the responsibility >>> of the caller to ensure that we do not pass a range, or split the range >>> covering a partial leaf mapping. >>> >>> This series is tied with Yang Shi's attempt [1] at using huge mappings >>> in the linear mapping in case the system supports BBML2, in which case >>> we will be able to split the linear mapping if needed without break-before-make. >>> Thus, Yang's series, IIUC, will be one such user of my series; suppose we >>> are changing permissions on a range of the linear map backed by PMD-hugepages, >>> then the sequence of operations should look like the following: >>> >>> split_range(start, (start + HPAGE_PMD_SIZE) & ~HPAGE_PMD_MASK); >>> split_range(end & ~HPAGE_PMD_MASK, end); >> I don't understand what the HPAGE_PMD_MASK twiddling is doing? That's not right. >> It's going to give you the offset within the 2M region. You just want: >> >> split_range(start) >> split_range(end) >> >> right? > > Suppose start = 2M + 4K, end = 8M + 5K. Then my sequence will compute to 8M + 5K is not a valid split point. It has to be at least page aligned. > split_range(2M + 4K, 3M) > split_range(8M, 8M + 5K) We just want to split at start and end. What are the 3M and 8M params supposed to be? Anyway, this is off-topic for this series. > __change_memory_common(2M + 4K, 8M + 5K) > > So now __change_memory_common() wouldn't have to deal with splitting the > starts and ends. Please correct me if I am wrong. > >> >>> __change_memory_common(start, end); >>> >>> However, this series can be used independently of Yang's; since currently >>> permission games are being played only on pte mappings (due to >>> apply_to_page_range >>> not supporting otherwise), this series provides the mechanism for enabling >>> huge mappings for various kernel mappings like linear map and vmalloc. >> In other words, you are saying that this series is a prerequisite for Yang's >> series (and both are prerequisites for huge vmalloc by default). Your series >> adds a new capability that Yang's series will rely on (the ability to change >> permissions on block mappings). > > That's right. > >> >> Thanks, >> Ryan >> >>> [1] https://lore.kernel.org/all/20250304222018.615808-1- >>> yang@os.amperecomputing.com/ >>> >>> Dev Jain (3): >>>    mm: Allow pagewalk without locks >>>    arm64: pageattr: Use walk_page_range_novma() to change memory >>>      permissions >>>    mm/pagewalk: Add pre/post_pte_table callback for lazy MMU on arm64 >>> >>>   arch/arm64/mm/pageattr.c | 81 +++++++++++++++++++++++++++++++++++++--- >>>   include/linux/pagewalk.h |  4 ++ >>>   mm/pagewalk.c            | 18 +++++++-- >>>   3 files changed, 94 insertions(+), 9 deletions(-) >>>