Re: [PATCH RFC v9 02/25] set_memory: Introduce set_memory_pkey() stub

[Linu Cherian <linu.cherian@arm.com>]

On Thu, Sep 03, 2026 at 06:41:33PM +0200, Kevin Brodsky wrote:
> On 01/09/2026 16:33, Linu Cherian wrote:
> > Kevin,
> >
> > On Tue, Aug 18, 2026 at 03:08:44PM +0100, 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
> > Could you make it explicit here why we are restricting this only
> > to the linear mapping range ? Would be helpful to add the reasoning
> > in the commit message and as comments.
> >
> > Essentially we are also making a assumption here that there are no
> > aliases to the linear map ?
> 
> We're not assuming this, this function is called on pages that are also
> mapped as part of the kernel image. But indeed it ignores aliases,
> unlike e.g. set_memory_ro(). Really its name is wrong as discussed below.

Just trying to understand, does it also imply that we dont have use cases that has aliases.

> 
> >> fallback.
> >>
> >> Signed-off-by: Kevin Brodsky <kevin.brodsky@arm.com>
> >> ---
> >>  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
> > Would be better to make this (linar map range)constraint on the API name or that passed
> > as a boolean flag ?
> 
> Indeed, in fact I've been thinking about renaming this function for a
> while and I've already done it locally :) It'll be set_direct_map_pkey()
> in the next version.

Okay.

> 
> > Also, it would be better to have the __is_lm_address checks in this generic wrapper which
> > then calls arch_set_memory_pkey ?
> 
> That's not unreasonable, but such pattern isn't used by other functions
> in set_memory.h and I'd rather not deviate too much without a good reason.

Ack.
> 
> - Kevin