Re: [PATCH v2 1/3] arm64: mm: Fix rodata=full block mapping support for realm guests

[Yang Shi <yang@os.amperecomputing.com>]

On 4/9/26 8:20 AM, Catalin Marinas wrote:
> On Thu, Apr 09, 2026 at 11:53:41AM +0200, Kevin Brodsky wrote:
>> On 07/04/2026 12:52, Catalin Marinas wrote:
>>>> if we have forced pte mapping then the value of
>>>> can_set_direct_map() is irrelevant - we will never need to split because we are
>>>> already pte-mapped.
>>> can_set_direct_map() is used in other places, so its value is
>>> relevant, e.g. sys_memfd_secret() is rejected if this function returns
>>> false.
>> Indeed, I have noticed this before: currently set_direct_map_*_noflush()
>> and other functions will either fail or do nothing if none of the
>> features (rodata=full, etc.) is enabled, even if we would be able to
>> split the linear map using BBML2-noabort.
> That's what I have been trying to say to Ryan ;), can_set_direct_map()
> has different meanings depending on the caller: hint that it might split
> or asking whether splitting is permitted. The latter is not captured.
> Ignoring realms, if we have BBML2_NOABORT the kernel won't force pte
> mappings under the assumption that split_kernel_leaf_mapping() is safe.
> However set_direct_map_*_noflush() won't even reach the split function
> because the "can" part says "no, you can't".
>
>> What would make more sense to me is to enable the use of BBML2-noabort
>> unconditionally if !force_pte_mapping(). We can then have
>> can_set_direct_map() return true if we have BBML2-noabort, and we no
>> longer need to check it in map_mem().
> Indeed.

I'm trying to wrap up my head for this discussion. IIUC, if none of the 
features is enabled, it means we don't need do anything because the 
direct map is not changed. For example, if vmalloc doesn't change direct 
map permission when rodata != full, there is no need to call 
set_direct_map_*_noflush(). So unconditionally checking BBML2_NOABORT 
will change the behavior unnecessarily. Did I miss something?

I think the only exception is secretmem if I don't miss something. 
Currently, secretmem is actually not supported if none of the features 
is enabled. But BBML2_NOABORT allows to lift the restriction.

Thanks,
Yang


>
>> This is a functional change that doesn't have anything to do with realms
>> so it should probably be a separate series - happy to take care of it
>> once the dust settles on the realm handling.
> I think it can be done in parallel, it shouldn't interfere with realms.
> The realm part should just affect force_pte_mapping() and
> can_set_direct_map() should return just what's possible, not what may
> need to set the direct map.
>