[RFC PATCH 2/6] arm64: mm: allow huge vmap permission adjustments with bbml2_no_abort

[Ryan Roberts]

On 11/06/2026 14:01, Adrian Barnaś wrote:
> Remove the protection against huge vmap permission adjustments on
> systems that support the bbml2_no_abort CPU feature.
> 
> Splitting live kernel VA section mappings into page mappings was
> restricted because it could cause TLB Conflict Aborts. This forced
> permission adjustments on memory allocated with VM_ALLOW_HUGE_VMAP to be
> rejected, resulting in performance drops (e.g., when enforcing rodata=on
> disables huge mappings).
> 
> The bbml2_no_abort feature (which mirrors the architectural guarantees of
> FEAT_BBML3) ensures that changing between table and block sizes without
> following a break-before-make sequence will not generate a TLB Conflict
> Abort. This hardware guarantee makes it safe to allow dynamic permission
> adjustments on huge vmap regions.

FYI Linu Cherian has a series that renames bbml2_no_abort to bbml3. I think he's
planning to post at -rc1. Would be good to rebase this on top once merged.

> 
> Signed-off-by: Adrian Barnaś <abarnas at google.com>
> ---
>  arch/arm64/mm/pageattr.c | 22 ++++++++++++++--------
>  1 file changed, 14 insertions(+), 8 deletions(-)
> 
> diff --git a/arch/arm64/mm/pageattr.c b/arch/arm64/mm/pageattr.c
> index 358d1dc9a576..88720bbba892 100644
> --- a/arch/arm64/mm/pageattr.c
> +++ b/arch/arm64/mm/pageattr.c
> @@ -157,23 +157,29 @@ static int change_memory_common(unsigned long addr, int numpages,
>  	}
>  
>  	/*
> -	 * Kernel VA mappings are always live, and splitting live section
> -	 * mappings into page mappings may cause TLB conflicts. This means
> -	 * we have to ensure that changing the permission bits of the range
> -	 * we are operating on does not result in such splitting.
> -	 *
>  	 * Let's restrict ourselves to mappings created by vmalloc (or vmap).
> -	 * Disallow VM_ALLOW_HUGE_VMAP mappings to guarantee that only page
> -	 * mappings are updated and splitting is never needed.
>  	 *
>  	 * So check whether the [addr, addr + size) interval is entirely
>  	 * covered by precisely one VM area that has the VM_ALLOC flag set.
>  	 */
>  	area = find_vm_area((void *)addr);
> +
>  	if (!area ||
>  	    ((unsigned long)kasan_reset_tag((void *)end) >
>  	     (unsigned long)kasan_reset_tag(area->addr) + area->size) ||
> -	    ((area->flags & (VM_ALLOC | VM_ALLOW_HUGE_VMAP)) != VM_ALLOC))
> +	    !(area->flags & VM_ALLOC))
> +		return -EINVAL;
> +
> +	/*
> +	 * Kernel VA mappings are always live, and splitting live section
> +	 * mappings into page mappings may cause TLB conflicts if bbml2_noabort
> +	 * is not present.
> +	 *
> +	 * While bbml2_noabort is not present disallow VM_ALLOW_HUGE_VMAP mappings
> +	 * to guarantee that only page mappings are updated and splitting is not
> +	 * needed.
> +	 */
> +	if (!system_supports_bbml2_noabort() && (area->flags & (VM_ALLOW_HUGE_VMAP)))

nit: no need for the parentheses around VM_ALLOW_HUGE_VMAP.

With that:

Reviewed-by: Ryan Roberts <ryan.roberts at arm.com>

>  		return -EINVAL;
>  
>  	if (!numpages)