On 16/06/2026 17:41, David Hildenbrand (Arm) wrote: > On 5/26/26 13:15, Kevin Brodsky wrote: >> Introduce a new function, set_memory_pkey(), which sets the >> protection key (pkey) of pages in the specified linear mapping >> range. Architectures implementing kernel pkeys (kpkeys) must >> provide a suitable implementation; an empty stub is added as >> fallback. >> >> Signed-off-by: Kevin Brodsky <[email protected]> >> --- >> include/linux/set_memory.h | 7 +++++++ >> 1 file changed, 7 insertions(+) >> >> diff --git a/include/linux/set_memory.h b/include/linux/set_memory.h >> index 3030d9245f5a..7b3a8bfde3c6 100644 >> --- a/include/linux/set_memory.h >> +++ b/include/linux/set_memory.h >> @@ -84,4 +84,11 @@ static inline int set_memory_decrypted(unsigned long >> addr, int numpages) >> } >> #endif /* CONFIG_ARCH_HAS_MEM_ENCRYPT */ >> >> +#ifndef CONFIG_ARCH_HAS_KPKEYS >> +static inline int set_memory_pkey(unsigned long addr, int numpages, int >> pkey) >> +{ >> + return 0; >> +} >> +#endif >> + >> #endif /* _LINUX_SET_MEMORY_H_ */ >> > This patch looks rather odd, given that this is just a stub that won't be used > before patch #20. > > And there, it's only used from arm64 code? So why do we need the common-code > stub?
It is primarily used in patch 12, the generic kpkeys page table allocator, so we do need a stub. The ordering might be a little confusing indeed, but I tried to follow the following order: 1. kpkeys/generic, 2. kpkeys/arm64, 3. kpkeys_hardened_pgtables/generic, 4. kpkeys_hardened_pgtables/arm64. Happy to reorder if you have other preferences. - Kevin
