Thread (18 messages) 18 messages, 4 authors, 2026-03-27

Re: [PATCH v1 2/3] arm64: mm: Handle invalid large leaf mappings correctly

From: Kevin Brodsky <hidden>
Date: 2026-03-23 19:56:20
Also in: lkml, stable

On 23/03/2026 18:25, Ryan Roberts wrote:
quoted
quoted
@@ -132,11 +137,12 @@ static int __change_memory_common(unsigned long start, unsigned long size,
 	ret = update_range_prot(start, size, set_mask, clear_mask);
 
 	/*
-	 * If the memory is being made valid without changing any other bits
-	 * then a TLBI isn't required as a non-valid entry cannot be cached in
-	 * the TLB.
+	 * If the memory is being switched from present-invalid to valid without
+	 * changing any other bits then a TLBI isn't required as a non-valid
+	 * entry cannot be cached in the TLB.
 	 */
-	if (pgprot_val(set_mask) != PTE_VALID || pgprot_val(clear_mask))
+	if (pgprot_val(set_mask) != (PTE_MAYBE_NG | PTE_VALID) ||
It isn't obvious to understand where all those PTE_MAYBE_NG come from if
one hasn't realised that PTE_PRESENT_INVALID overlays PTE_NG.

Since for this purpose we always set/clear both PTE_VALID and
PTE_MAYBE_NG, maybe we could define some macro as PTE_VALID |
PTE_MAYBE_NG, as a counterpart to PTE_PRESENT_INVALID?
How about:

#define PTE_PRESENT_VALID_KERNEL	(PTE_VALID | PTE_MAYBE_NG)

The user space equivalent has NG clear, so important to clarify that this is the
kernel value, I think.
Sounds good to me.

- Kevin
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help