Re: [PATCH v8 0/5] arm64: support FEAT_BBM level 2 and large block mapping when rodata=full

[Ryan Roberts]

On 17/03/2026 12:43, Kevin Brodsky wrote:
> On 17/03/2026 12:45, Ryan Roberts wrote:
>> On 17/03/2026 09:29, Kevin Brodsky wrote:
>>> On 17/03/2026 10:13, Ryan Roberts wrote:
>>>>>>> Another option would be to initially map by pte then collapse to
>>>>>>> block mappings
>>>>>>> once we have determined that all cpus support BBML2_NOABORT. We
>>>>>>> originally opted
>>>>>>> not to do that because it's a tax on symetric systems. But we could
>>>>>>> throw in the
>>>>>>> towel if it's the least bad solution we can come up with for solving
>>>>>>> this. I
>>>>>>> think it might help some of Kevin's use cases too?
>>>>>> May be an option too. When we discussed this there was no usecase for
>>>>>> direct mapping collapse. But if we can have multiple usecases, it may
>>>>>> be worth it. 
>>>> I could imagine that if user space creates and destroys lots of secretmem areas,
>>>> then it will completely split the linear map to ptes and that will never recover
>>>> currently. So I think in the long term, having the ability to collapse would be
>>>> useful. I just don't particularly like forcing symetric systems to map by pte
>>>> initially (which is slow) only to collapse later (which will cost even more
>>>> time). But it does feel inherrently more robust.
>>> Now that you spell it out, I'm realising this would actually make things
>>> pretty complicated for protected page tables. In that series, page
>>> tables for the linear map are allocated by a separate memblock-based
>>> allocator [1], tracking the allocated ranges to set their pkey later.
>>> There's a strong assumption that these page tables are never freed.
>>>
>>> If we initially PTE-mapped the linear map and then later collapsed it,
>>> that assumption clearly wouldn't hold. 
>> Sorry I don't understand why the assumptions change? All I'm proposing is walkng
>> the linear map to find compatible PTEs and collapsing them into the biggest
>> possible blocks. The pages aren't being freed, they are just being mapped
>> differently (which can be done live for BBML2_NOABORT). PTEs with different
>> pkeys would be considered incompatible, so we would end up with a boundary in
>> the leaf mappings at that point.
> 
> I'm not sure I'm following, if all entries in a PTE page are compatible,
> then surely we just convert the parent PMD entry to become a leaf and
> then free the PTE page? And same idea one level above.

Ahh - good point! That totally passed me by before. But I'm not sure it's the
end of the world...

We would end up with about 0.2% (4K/2M if I've done my maths correctly?) of the
linear map sub-optimally mapped. Personally I don't think that would be the end
of the world.

> 
>>
>>> It could be handled by poking
>>> holes in the tracked ranges, but it gets ugly and increases fragmentation.
>> You'd still want page tables to be allocated from contiguous physical (and
>> virtual) memory so that the boundaries where pkeys change are minimized.
> 
> Yes that's for sure, that's why I'm concerned with individual pages
> being freed in a middle of a block.
> 
>> I guess I've misunderstood something...
> 
> I might have too :/
> 
> - Kevin