Re: [PATCH v4] arm64: Enable permission change on arm64 kernel block mappings

[Dev Jain]

On 24/07/25 5:28 pm, Catalin Marinas wrote:
> On Thu, Jul 24, 2025 at 04:10:18PM +0530, Dev Jain wrote:
> > On 24/07/25 1:49 pm, Catalin Marinas wrote:
> > > On Thu, Jul 03, 2025 at 08:44:41PM +0530, Dev Jain wrote:
> > > > arm64 currently changes permissions on vmalloc objects locklessly, via
> > > > apply_to_page_range, whose limitation is to deny changing permissions for
> > > > block mappings. Therefore, we move away to use the generic pagewalk API,
> > > > thus paving the path for enabling huge mappings by default on kernel space
> > > > mappings, thus leading to more efficient TLB usage. However, the API
> > > > currently enforces the init_mm.mmap_lock to be held. To avoid the
> > > > unnecessary bottleneck of the mmap_lock for our usecase, this patch
> > > > extends this generic API to be used locklessly, so as to retain the
> > > > existing behaviour for changing permissions.
> > > Is it really a significant bottleneck if we take the lock? I suspect if
> > > we want to make this generic and allow splitting, we'll need a lock
> > > anyway (though maybe for shorter intervals if we only split the edges).
> > The splitting primitive may or may not require a lock, Ryan and Yang had
> > some discussion on the linear map block mapping thread. I am assuming
> > that since we didn't need a lock in the past, there is no need to take it now,
> > since we are only changing the pagetable walk API being used.
> I vaguely remember Ryan's and Yang's discussion. I'd have to revisit it.
> In the past we were not replacing block/table entries since there was no
> page table splitting. If we are to add some splitting, even at the
> edges, what would prevent some other caller of this API overlapping and
> attempting to do the same split? It's not just vmalloc ranges but the
> linear map as well that's touched by __change_memory_common().

Sorry I wasn't clear enough, what I meant to say was that the locking
will be the concernment of the splitting primitive - once that is done,
update_range_prot() does not need to take the lock.

>