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

[Kevin Brodsky]

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.

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