Re: [PATCH RFC v9 13/25] mm: kpkeys: Introduce early page table allocator

[Kevin Brodsky <kevin.brodsky@arm.com>]

On 27/08/2026 20:17, Dave Hansen wrote:
> On 8/18/26 07:08, Kevin Brodsky wrote:
>> This patch addresses the second category: PTPs allocated via memblock.
>> Such PTPs are notably used to create the linear map. Protecting them as
>> soon as they are allocated would require modifying the linear map while
>> it is being created, which seems at best difficult. Instead, a
>> simple allocator is introduced, obtaining pages from memblock and
>> keeping track of all allocated ranges to set their pkey once it is
>> safe to do so.
> What makes setting a pkey on the memory "unsafe"? Is there something
> preventing just making access permissive during boot?

There are two issues at play here:

1. When allocating page tables to create the direct map, we cannot
reliably set their pkey because that itself requires modifying the
direct map (and we may not even have mapped this particular page yet).
There may be ways around this, but it feels at best uncomfortable.

2. Specifically in the context of relying on the BBML3 feature on arm64:
when we create the direct map with large block mappings, there is a
window during boot (before all the secondary cores are up) where we do
not allow splitting blocks. This has caused troubles for other features
as well, see [1].

My understanding is that 1. is a problem regardless of the architecture.
2. is not actually relevant when we force the direct map to be
PTE-mapped, as is the case in this version, but it had to be considered
in RFC v6 where we tried to support block mappings.

As per the discussion with David (also in reply to this patch), the plan
is now to return to an earlier design where we walk the early kernel
page tables to set their pkey. This circumvents the allocation question
completely, albeit with the requirement that the direct map is fully
PTE-mapped.

- Kevin

[1]
https://lore.kernel.org/all/0b2a4ae5-fc51-4d77-b177-b2e9db74f11d@huawei.com/
[2]
https://lore.kernel.org/all/20260227175518.3728055-19-kevin.brodsky@arm.com/