Re: [PATCH 1/2] arm64/pageattr: Propagate return value from __change_memory_common

[Ryan Roberts <ryan.roberts@arm.com>]

On 24/11/2025 15:11, Will Deacon wrote:
> On Thu, Nov 13, 2025 at 11:55:48AM +0000, Ryan Roberts wrote:
>> On 12/11/2025 06:27, Dev Jain wrote:
>>> The rodata=on security measure requires that any code path which does
>>> vmalloc -> set_memory_ro/set_memory_rox must protect the linear map alias
>>> too. Therefore, if such a call fails, we must abort set_memory_* and caller
>>> must take appropriate action; currently we are suppressing the error, and
>>> there is a real chance of such an error arising post commit a166563e7ec3
>>> ("arm64: mm: support large block mapping when rodata=full"). Therefore,
>>> propagate any error to the caller.
>>>
>>> Fixes: a166563e7ec3 ("arm64: mm: support large block mapping when rodata=full")
>>> Signed-off-by: Dev Jain <dev.jain@arm.com>
>>
>> Reviewed-by: Ryan Roberts <ryan.roberts@arm.com>
>>
>> It would be good to get this into v6.18 I guess?
> 
> I'm not sure I see the urgency. When the commit message says:
> 
>   "there is a real chance of such an error arising post commit a166563e7ec3"
> 
> afaict that's either due to -ENOMEM 

Yes this is the main risk; failing to allocate an intermediate page table during
split_kernel_leaf_mapping(). I have no idea how likely that is in production.
The only data point I have is that for the theoretical memory hotplug -ENOMEM
that Chaitanya and Linu fixed recently, we tried to provoke it by hotplugging a
lot of memory on a system under high memory pressure; no matter what we did, we
couldn't get that 4K pgtable allocation to fail. So on that basis, I think we
are unlikely to see it.

> or some hideous issue with the
> page-tables (e.g. the -EINVALs in pageattr_pXd_entry() seem completely
> unnecessary to me).

I thought the -EINVALs were trying to catch the case where someone tries to set
permissions on a sub-portion of a vmalloc_huge() area on a system that doesn't
support BBML2_NOABORT. But looking again, we already refuse vmalloc_huge in
change_memory_common.

> 
> Do you think failure is actually likely and recoverable?

As above, I think failure is unlikely, but not impossible. I guess the result
would be memory that remains RW when it should have been set RO or RX. But I
think it will all work itself out at vfree. I think.

We can defer this to next cycle if you prefer.

Thanks,
Ryan

> 
> Will