Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Vincent Donnefort <vdonnefort@google.com>
To: catalin.marinas@arm.com, will@kernel.org, rafael@kernel.org
Cc: mark.rutland@arm.com, lenb@kernel.org, pavel@kernel.org,
	 linux-arm-kernel@lists.infradead.org, linux-pm@vger.kernel.org,
	 linux-kernel@vger.kernel.org, thierry.reding@kernel.org,
	rppt@kernel.org,  Vincent Donnefort <vdonnefort@google.com>
Subject: [PATCH v1 4/4] arm64: mm: Allow can_set_direct_map() on BBML3 systems
Date: Fri, 18 Sep 2026 14:16:56 +0100	[thread overview]
Message-ID: <20260918131656.3710047-5-vdonnefort@google.com> (raw)
In-Reply-To: <20260918131656.3710047-1-vdonnefort@google.com>

On BBML3 systems, block mappings in the linear map can be split
dynamically at runtime without break-before-make faults. In such
systems, allow can_set_direct_map() to enable set_direct_map_* users.

split_kernel_leaf_mapping() must now allow splitting for BBML3 systems
where no feature requires a split (i.e. !linear_map_needs_set()). As a
consequence, it can't solely rely on linear_map_requires_bbml3 anymore.
Instead, deduce force_pte_mapping() value and filter out non-lm
addresses.

Signed-off-by: Vincent Donnefort <vdonnefort@google.com>
---
 arch/arm64/mm/mmu.c      | 24 +++++++++++++++---------
 arch/arm64/mm/pageattr.c |  2 +-
 2 files changed, 16 insertions(+), 10 deletions(-)

diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index c18ed601f0a8..4c345065d33f 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -811,24 +811,30 @@ static bool linear_map_requires_bbml3;
 
 int split_kernel_leaf_mapping(unsigned long start, unsigned long end)
 {
+	bool force_pte;
 	int ret;
 
 	/*
 	 * If the region is within a pte-mapped area, there is no need to try to
-	 * split. Additionally, CONFIG_DEBUG_PAGEALLOC and CONFIG_KFENCE may
-	 * change permissions from atomic context so for those cases (which are
-	 * always pte-mapped), we must not go any further because taking the
-	 * mutex below may sleep. Do not call force_pte_mapping() here because
-	 * it could return a confusing result if called from a secondary cpu
-	 * prior to finalizing caps. Instead, linear_map_requires_bbml3 gives us
-	 * what we need.
+	 * split:
+	 *
+	 * Do not call force_pte_mapping() here because it could return a
+	 * confusing result if called from a secondary cpu prior to finalizing
+	 * caps. Instead, retrieve that value with linear_map_requires_bbml3.
+	 *
+	 * Additionally, CONFIG_KFENCE may change permissions from atomic
+	 * context so for this case (which is always pte-mapped), we must not go
+	 * any further because taking the mutex below may sleep.
+	 *
+	 * Finally, set_memory_* can be called on PTE-mapped vmalloc mappings.
 	 */
-	if (!linear_map_requires_bbml3 || is_kfence_address((void *)start))
+	force_pte = !linear_map_requires_bbml3 && linear_map_needs_set();
+	if (force_pte || is_kfence_address((void *)start) || !__is_lm_address(__tag_reset(start)))
 		return 0;
 
 	if (!system_supports_bbml3()) {
 		/*
-		 * BBML3 systems should not be trying to change
+		 * Non-BBML3 systems should not be trying to change
 		 * permissions on anything that is not pte-mapped in the first
 		 * place. Just return early and let the permission change code
 		 * raise a warning if not already pte-mapped.
diff --git a/arch/arm64/mm/pageattr.c b/arch/arm64/mm/pageattr.c
index c1ba74eb602f..f952cc125705 100644
--- a/arch/arm64/mm/pageattr.c
+++ b/arch/arm64/mm/pageattr.c
@@ -89,7 +89,7 @@ bool rodata_full __ro_after_init = true;
 
 bool can_set_direct_map(void)
 {
-	return linear_map_needs_set();
+	return linear_map_needs_set() || system_supports_bbml3();
 }
 
 static int update_range_prot(unsigned long start, unsigned long size,
-- 
2.55.0.1082.g2b9226bbc0-goog



      parent reply	other threads:[~2026-09-18 13:19 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-18 13:16 [PATCH v1 0/4] arm64: mm: Allow set_direct_map functions on BBML3 systems Vincent Donnefort
2026-09-18 13:16 ` [PATCH v1 1/4] PM: hibernate: Add arch specific hooks for hibernate_map/unmap_page Vincent Donnefort
2026-09-22  5:55   ` Mike Rapoport
2026-09-18 13:16 ` [PATCH v1 2/4] arm64: hibernate: Use fixmap " Vincent Donnefort
2026-09-18 13:16 ` [PATCH v1 3/4] arm64: mm: Introduce linear_map_needs_set() helper Vincent Donnefort
2026-09-18 13:16 ` Vincent Donnefort [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260918131656.3710047-5-vdonnefort@google.com \
    --to=vdonnefort@google.com \
    --cc=catalin.marinas@arm.com \
    --cc=lenb@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=pavel@kernel.org \
    --cc=rafael@kernel.org \
    --cc=rppt@kernel.org \
    --cc=thierry.reding@kernel.org \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox