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 CC816C71148 for ; Fri, 13 Jun 2025 13:44:05 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6E7FF6B00A2; Fri, 13 Jun 2025 09:44:05 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6BFBA6B00A3; Fri, 13 Jun 2025 09:44:05 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5FEBF6B00A4; Fri, 13 Jun 2025 09:44:05 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 416316B00A2 for ; Fri, 13 Jun 2025 09:44:05 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id ECBB2C0817 for ; Fri, 13 Jun 2025 13:44:04 +0000 (UTC) X-FDA: 83550496008.14.E2022A4 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf21.hostedemail.com (Postfix) with ESMTP id 34B9B1C0003 for ; Fri, 13 Jun 2025 13:44:03 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=none; spf=pass (imf21.hostedemail.com: domain of dev.jain@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=dev.jain@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=1749822243; 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-transfer-encoding:content-transfer-encoding: in-reply-to:references; bh=/ejW372tLidV6m7pAYZ/EWeHW7tRte3yRmvT+hobzE0=; b=vPba2uOqWsYP5GrOYFrQM48dqA0JrIyK9nXFX0DZhLNnkQhTgxcJTYOX6/gtwbI6pk6t5F ettz9kYn3wGRaWqX7RgU4HVbPycIZ+jqABSYkWm9ZoSaLZflrzgQG9G+obRd2IHUS7FEM0 lmhkx2k1mdE3CK7se7pEBd3wFtNZgds= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=none; spf=pass (imf21.hostedemail.com: domain of dev.jain@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=dev.jain@arm.com; dmarc=pass (policy=none) header.from=arm.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1749822243; a=rsa-sha256; cv=none; b=6NBIOuvAjGMrhiMPLsvy1jZs6VRzZ5M7p7OsZoc+r5xuuOCgRA3LoNAg7fJEnaBh9WphAq fK56DIYCH3z0OOzeJOszHVyKDhbQROiTEbgF/zVoYcbYL3qStcq+lJ8VhrrUWYn+mq1VWC KuGmIkuypGbcHiKmI89P6bRkheAyg9E= 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 D264F2B; Fri, 13 Jun 2025 06:43:41 -0700 (PDT) Received: from MacBook-Pro.blr.arm.com (MacBook-Pro.blr.arm.com [10.164.18.48]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 89B9A3F59E; Fri, 13 Jun 2025 06:43:56 -0700 (PDT) From: Dev Jain To: 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, yang@os.amperecomputing.com, ryan.roberts@arm.com, anshuman.khandual@arm.com, Dev Jain Subject: [PATCH v3 0/2] Enable permission change on arm64 kernel block mappings Date: Fri, 13 Jun 2025 19:13:50 +0530 Message-Id: <20250613134352.65994-1-dev.jain@arm.com> X-Mailer: git-send-email 2.39.3 (Apple Git-146) MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 34B9B1C0003 X-Rspamd-Server: rspam07 X-Stat-Signature: eynop3xrec6q3y6icp3aoa1ngase3t1x X-Rspam-User: X-HE-Tag: 1749822243-354113 X-HE-Meta: U2FsdGVkX199YOTe5AK6EZj6BzihBdqG2bu6ZeWEygVSXcgCkkP15o9Y0bsdl68ZtAyAinP07mzzOXMyS2+KmWsIYBSka2edeGzxZ/BuzCAtVzlJEVYZLSbGMvd/GnZsGBCgB7cdHAKNeZ+g3W4/NqaC9Zlh/M9SHhhHje9xOcfn2NUiB/vtoB3/VbORWML099mXJIo15zLqg/xtsOW8NW04s2vfbgPRdC0ny04VU0GWx5r0MDRLa6GveqlszPHnUePaNw9uxxGVFmHxhQNR04BccwuvQESXJ9wbD7kBvMoNJS8GyuRXarCtt2MhxRL4R58jj3toY5tS3dFvZxJFkRMpBu7gKClqGBT/LAiY+BUTHcfQFAGEv6lx5fgCaGuXM71j9/Hoqv5RrIT1tNNYGy34A80gbfS5Hn5np/UuJ2plUHxAuwBKzxc4sXuCDWyzxH3YB9tyTOz8h5J27r5gf67RO6PQWKXcIFgSP84GxoYsapDsbwxBKh0JJql1/suOAF0dO1u1QE7NR4IvIa7xX19boLvMujgPaYiGkxZ4GcciSlF7C0pDXJt9jG59m8QLEwDpnwRsfroV9WPGjM1KmKpIj6r3flpyANK7CJiuDVFmG8Fvfq36iNVS21XVNKX5bMkcugzLQLKtxGSGhhjpTqKUD8oChe2nyGC1EeCrtIsH6nkWl2ClOmy1RTcn11VP7UeFDcyyo1AneEq854vkti+Q8N7PTyVNhsVCo8oFc+ByvpQk36Qbc449WkGP1MugkL/K0b08vveKqRBrzUJdVIGrAEsCaz8FL7Ar+Uo6cLR6Os+z4aelNqEJP58DYrwQ26TJTBuKayUdedssdKJ6Islch+IsmB4AlzlSu7ggI32w1R1CuZ1GYJDHN+qCxg31tfYKt6jY4BvMchBGyPHhUK+xSWD1lO7SBpNQJAhcHisQPzgOvi8B70b3nLheJiZcPuCNdTtiwIHJEURxvxw Jf0U5hb9 XTQTc+auVaGqoJRjH1bbKi2uDeTtbo50jBfh91/iMfFcm6pBifW+b01TRYgRxduGRoiNzwLzHOF/ZhDZuaPfTEkhVsc2zBLhZWoQCm5Hg8YwLiTBpUtZ2C2bVNzMP9sUG/+YDmncFmp+f5m23ZYkPObeQHHD1MsS/G+5455PboRxwahXEeurBEMz2vk8qCNdM/esvu71oPLh1bT1HV1ewZ9V2z16CpJZObCsePak6Ju7Uhb0= 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: This series paves the path to enable huge mappings in vmalloc space and linear map space by default on arm64. For this we must ensure that we can handle any permission games on the kernel (init_mm) pagetable. Currently, __change_memory_common() uses apply_to_page_range() which does not support changing permissions for block mappings. We attempt to move away from this by using the pagewalk API, similar to what riscv does right now; however, it is the responsibility of the caller to ensure that we do not pass a range overlapping a partial block mapping; in such a case, the system must be able to support splitting the range (which can be done on BBM2 systems). 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) split_range(end); ___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. [1] https://lore.kernel.org/all/20250304222018.615808-1-yang@os.amperecomputing.com/ v2->v3: - Drop adding PGWALK_NOLOCK, instead have a new lockless helper - Merge patch 1 and 2 from v2 - Add a patch *actually* enabling vmalloc-huge permission change v1->v2: - Squash patch 2 and 3 - Add comment describing the responsibility of the caller to ensure no partial overlap with block mapping - Add comments and return -EINVAL at relevant places to document the usage of PGWALK_NOLOCK (Lorenzo) - Nest walk_kernel_page_table_range() with lazy_mmu calls, instead of doing so only per PTE level, fix bug in the PTE callback, introduce callbacks for all pagetable levels, use ptdesc_t instead of unsigned long, introduce ___change_memory_common and use them for direct map permission change functions (Ryan) v1: https://lore.kernel.org/all/20250530090407.19237-1-dev.jain@arm.com/ Dev Jain (2): arm64: pageattr: Use pagewalk API to change memory permissions arm64: pageattr: Enable huge-vmalloc permission change arch/arm64/mm/pageattr.c | 161 ++++++++++++++++++++++++++++++--------- include/linux/pagewalk.h | 3 + mm/pagewalk.c | 26 +++++++ 3 files changed, 155 insertions(+), 35 deletions(-) -- 2.30.2