[PATCH RFC v8 01/24] mm: Introduce kpkeys

[David Hildenbrand (Arm)]

On 6/18/26 15:22, Linus Walleij wrote:
> On Tue, Jun 16, 2026 at 5:19 PM David Hildenbrand (Arm)
> <david at kernel.org> wrote:
> 
>> Looking at this, and wondering about "why do we get registers involved in this
>> API" I would probably have an interface like:
>>
>>         arch_kpkeys_enter_context()
>>         arch_kpkeys_leave_context()
>>
>> Whereby you return a "struct kpkeys_state" or sth like that.
> 
> This is close to what I was looking for as well.

Cool :)

> 
> enter/leave makes the code look more like generic entry.
> 
> Passing some kind of state cookie around is inevitable in
> this design and IIUC Kevin argued that it would be inefficient
> (another level of abstraction) as opposed to just hammering
> in the context we want, where we want it.
> 
> But I think the compiler will optimize that out by constant
> propagation if the backing architecture implementation is
> simple.

Yes, it should be wrapped somehow. I don't think this will be a problem
performance-wise that cannot be solved differently.

Returning an u64 ("register") here is really arm64-sepcific and should be
abstracted.

-- 
Cheers,

David