Re: [RFC PATCH 3/6] arm64: mm: fix restoring linear map permissions on execmem cache clean

[Mike Rapoport <rppt@kernel.org>]

Hi Adrian,

On Wed, Jun 17, 2026 at 03:18:27PM +0000, Adrian Barnaś wrote:
> On Fri, Jun 12, 2026 at 10:17:55AM +0300, Mike Rapoport wrote:
> > > 
> > > Hm, maybe desirable for execmem but that doesn't really mean the x86
> > > behaviour is correct. Maybe it makes more sense to change the x86
> > > to align with the arm64 behaviour here?
> > > 
> > > BTW we should probably document this API a little bit, I never thought
> > > abut what "valid" actually means until now. I had thought of it as "I
> > > can access this memory" but that's an unclear concept and now I realise
> > > "valid" is a technical concept in Arm that's confusing. And it's extra
> > > confusing if the kernel API uses "valid" to mean a _different_ thing.
> > 
> > I've got confused too and that's how set_direct_map_valid() got into x86
> > with a different semantics than on arm64.
> > 
> > What execmem really needs is set_direct_map_default() variant that gets
> > nr_pages.
> > 
> > AFAIR, set_direct_map_default() has a single 'page' parameter because it
> > was added to reset permissions for the direct map alias for vmalloc()'ed
> > pages before there was VMALLOC_HUGE and each page had to be reset
> > independently anyway.
> > 
> > Maybe it's time to add nr_pages to set_direct_map_valid().
> 
> I was also quite confused by this initially. I spent some time debugging
> until I realized why unloading all the modules was causing the kernel to
> crash.
> 
> The reason I took this approach was that I wanted to send out a working
> prototype for arm64 that wouldn't interfere with the existing, working
> implementation on x86.
> 
> Following your suggestion, I can put together a preparatory patch series to
> refactor the set_direct_map_* APIs to accept a nr_pages parameter. This

There was a patch Nikita sent a while ago that does something similar:

https://lore.kernel.org/all/20260410151746.61150-2-kalyazin@amazon.com

I believe you can start from there.

> refactoring would also allow us to drop the redundant set_area_direct_map

We can't drop set_area_direct_map() because vmalloc pages might be not
physically contiguous.

> helper. I could then rebase the rox_cache series on top of that.
> 
> Does this sound like a good path forward?
> 
> Thanks,
> Adrian

-- 
Sincerely yours,
Mike.