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

["Adrian Barnaś" <abarnas@google.com>]

On Wed, Jun 17, 2026 at 09:40:25PM +0300, Mike Rapoport wrote:
>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.
>

I will pick the 01 patch from there to my series.

>> 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.
>

Agree.

>> 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.

Thanks,
Adrian