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 E802AC5B543 for ; Tue, 10 Jun 2025 11:44:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4DEF96B007B; Tue, 10 Jun 2025 07:44:18 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 469B76B0089; Tue, 10 Jun 2025 07:44:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 331156B008A; Tue, 10 Jun 2025 07:44:18 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 11ABE6B007B for ; Tue, 10 Jun 2025 07:44:18 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id B01511D8199 for ; Tue, 10 Jun 2025 11:44:17 +0000 (UTC) X-FDA: 83539307754.15.38C517A Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf29.hostedemail.com (Postfix) with ESMTP id EE97B12000C for ; Tue, 10 Jun 2025 11:44:15 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf29.hostedemail.com: domain of dev.jain@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=dev.jain@arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1749555856; 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=1cJe902L5Fmu1I390q3hKJDnbyZton5mKNCwWQ2f1zs=; b=T1B0B3khc/T9hfPr8rTpJC9gpUpjUO5bW4Q74GOxLxDLcGlxKsPXm1Pk1EC8yBHbTSF/K4 ua7wr2AO95qP8uLEJgWE1b5REc5Qp8Ptc/HdSdz+M2e1aV4hUmSkmW8NCX3QYzxljsCxUQ oQdO42SVVH8j6Fbm7YYcP8wqMGHbihI= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf29.hostedemail.com: domain of dev.jain@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=dev.jain@arm.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1749555856; a=rsa-sha256; cv=none; b=v2gkpeCKbvznaAwCcgbHobcBNBNRNonOBomdWhIu2ppl75D6RQRaQ0KIZQ8zrTnFdBrXI2 75jJm1byKw1pl/igxPsSjBMqT+ZOnk1WHmXxp4Kkgx5ez6vxI0iQtnlxtD0gLQGCJiR2ug CRbWiaDTLYTjFqv7jgeYT2/Y4nw2LXs= 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 A987C169C; Tue, 10 Jun 2025 04:43:55 -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 3B5713F59E; Tue, 10 Jun 2025 04:44:08 -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 v2 0/2] Enable permission change on arm64 kernel block mappings Date: Tue, 10 Jun 2025 17:13:59 +0530 Message-Id: <20250610114401.7097-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-Rspam-User: X-Rspamd-Queue-Id: EE97B12000C X-Rspamd-Server: rspam09 X-Stat-Signature: 9iaxbyko3cst68we5pe6ur4dgsg6fenj X-HE-Tag: 1749555855-314661 X-HE-Meta: U2FsdGVkX18DqS0PEnRZtYMZ/FhnJwaJjg/qoYVbHT7PxRZgzQ4pR9/1D/zN6KLPwWanyGtTHaFFfa1dHK291UFXwR6Kt8++JaLFLfUrkh4QzEXNDUIMGBalqN3VYB5pYmrG8bLuO9zUrbFkGkPqfjD89lP5hMgwsIp+PFeonFTAnoUpGW4iuldP6OtXxH+QEe4eHWifh9v5X1/eVwicA8W5VDV/GhPUHmPF2CH3CugoLbgRQRZiXgzQ/6pd/i940zhEkP42XKRn1rwgETSsG7zM5BMbda+tLBo0tEPGe+XpICpJ7/MezLqou2uvn7SXColw6fmBUiwonxjzBLicrW1QEalL2NOieSMP12PPhaKCzOo+/l9jztXmpiQhHs7Gz410XjP4jkbhfG6SXssv9MvsuBw4CW7biQdgouKNHphtdaKDEnUlXehZJDPUPod2D3U8cfHIcMWp+K+yGysDVLi0LkaAqMn9+VGozmF1hrx7Sv9TW+qzLNSvWg57vONnigWESWn2OmHdZVrSzvLzwuoUsVoOmVJoOFtG4/1eZOnE2zrh+TECGwesBuWoXLz5ZHJYVaAVxCqLG6eQD3545l2VhwLSfOSR/7WSkNmTsOt0Qg3sfE1QXGGXRw9r1iAcbfMyeL4+QxHy24d3jHGlGQLQL/rbYWv6hV31cFa8KRk+ekaJEVd8GScEUeHBkmNtaldDbEpjey1JTfTbO0gK8xV1KKW5INgw0Z7JovoVaaksj3SEJyBtTO7l805DiMs46ce+AtQsAMoQScKXkKO9LgsJfus/5TtVdVffmceLElB3DqxVXHCTgSfwIR0TEaaSrursUGgXDvhTySxeMrje4xoCcM3e4n1kaj1BSz0Lqox5cmNiZtTfe28pwT2OG3pm5k6L12N7RrjDQhfQu0+I37hdjGxaK/mfmrJqvnZ0GPMIE1dSTlK+T791eejYrBB4mwKFR4QWZLU4ZE3rH4x TZoREx3G ArbaP7hc0kGns9OAhVfBdVH7XcAl01kXaBwd7pxDIzHc4VL2GbytxUIHwDD6ZHEiZbZpppXpYdsBNIcwPxNse9VmQ55Qr9g2gaQ1r9JN9m+orDBZgrPEoGuvEBaa9uZFz71I+Snt7r9LUvkcJUC43fC2Mw9sTuS11q9fL4lKYLa1vsXitCgtec5olFs7vIb76zLuWXzjMF7BNv/7lAMIlEd1TH0OStkRM857+O8q1H3LULhE= 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 leaf mappings. 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) 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/ 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): mm: Allow lockless kernel pagetable walking arm64: pageattr: Use walk_page_range_novma() to change memory permissions arch/arm64/mm/pageattr.c | 158 +++++++++++++++++++++++++++++++-------- include/linux/pagewalk.h | 7 ++ mm/pagewalk.c | 23 ++++-- 3 files changed, 151 insertions(+), 37 deletions(-) -- 2.30.2