[RFC PATCH 6/6] arm64: mm: support PMD page coalescing in the linear map

[Mike Rapoport]

On Mon, Jul 06, 2026 at 12:41:29PM +0000, Adrian Barnaś wrote:
> Hi Mike,
> 
> On Fri, Jun 19, 2026 at 02:40:40PM +0100, Ryan Roberts wrote:
> 
> > I don't think this is safe in general. Let's say we have a 2M region split into
> > 512 x 4K PTEs. It's possible that the first 1M is one object and the second 1M
> > is another object. Different CPUs could set_memory_*() on those 2 objects
> > concurrently. If one of them then calls this function, we could end up
> > collapsing the whole 2M while the other is trying to modify the PTEs and they
> > will race.
> > 
> > Note that splitting _is_ safe (and protected by this lock) because you'd have 2
> > objects backed by the same PMD, so they would both have to split before
> > modifying the PTEs.
> > 
> > I think you'd need to ensure mutual exclusion at a higher level if doing this;
> > probably execmem is the place that can ensure that no objects within a 2M region
> > are racily trying to modify their permissions?
> > 
> > Thanks,
> > Ryan
> 
> I wonder what do you think about enforcing mutual exclusion for permission
> changes to the ROX_CACHE block as Ryan sugest?
> 
> Would it be appropriate to add locks (over `&execmem_cache.mutex`) to
> `execmem_force_rw` and `execmem_restore_rox`?
>                                                                             I
> see that x86 has a lock that wraps entire process of updating attributes
> (including spliting and collapsing pages):
> ```
> spin_lock(&cpa_lock);
> ret = __change_page_attr(cpa, primary);
> spin_unlock(&cpa_lock);                                            ```
> As I understand it makes it safe already.
> However, on ARM64 there is a split lock (which works fine for spliting) but
> for collapsing at least on my implementation it is not sufficient as
> Ryan pointed out.

I think the lock should be at set_memory level so that set_memory callers
shouldn't care about the differences in arch implementations.

I also suspect that the lockless page table walk in update_range_prot()
isn't safe today.
 
> Best regards
> Adrian

-- 
Sincerely yours,
Mike.