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

[Adrian Barnaś]

On Thu, Jun 18, 2026 at 03:21:24PM +0100, Ryan Roberts wrote:
>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.
>

I will keep an eye on next releases.

>>
>> 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)
>

Thanks,
Adrian