Re: [v8 PATCH] arm64: mm: show direct mapping use in /proc/meminfo

[Yang Shi]

On 7/28/26 4:37 AM, Lorenzo Stoakes (ARM) wrote:
> On Tue, Jul 28, 2026 at 10:27:17AM +0100, Will Deacon wrote:
> > On Mon, Jul 27, 2026 at 12:50:59PM -0700, Yang Shi wrote:
> > > On 7/22/26 4:31 AM, Will Deacon wrote:
> > > > > Yes, it may race with memory hotplug. I missed memory hotplug for v7
> > > > > Sashiko. Two options to solve it:
> > > > >
> > > > > 1. Use atomic variables. Make lm_meminfo[NR_LM_TYPE] atomic_long_t, then
> > > > > manipulate it with atomic ops.
> > > > > 2. Protect it with a spin lock.
> > > > >
> > > > > The contention for the cache line or the spin lock should be rare since
> > > > > memory hotplug should happen rarely. Any preference?
> > > > I'd vote for keeping it simple and using a lock. Might be worth looking
> > > > at the ongoing work from Lorenzo:
> > > >
> > > > https://lore.kernel.org/all/20260717-series-vmap-race-fix-v5-0-606a0ac6d3e5@xxxxxxxxxx/
> > > Thanks, Will. Took a look at Lorenzo's work. IIUC he used init_mm mmap_lock
> > > to protect vmalloc area and linear mapping collapse on x86 in order to
> > > serialize against ptdump. I don't think we should use init_mm mmap_lock. We
> > > want to serialize linear mapping counter update between split and memory
> > > hotplug, but neither of them takes init_mm mmap_lock. We can let them take
> > > init_mm mmap_lock, but it sounds too overkilling.

Hi Will and Lorenzo,

I will reply both of you in the same thread because both your replies 
are discussing the same thing.

> > Hmm, but if split and hotplug don't take the mmap_lock, how are they
> > serialised against ptdump? From what I understood, Lorenzo's patches
> > change ptdump to take it for write in order to serialise against other
> > walkers.

hotplug and ptdump is serialized by mem_hotplug_lock. We actually don't 
serialize between split and ptdump because ptdump should either see 
block or table. Split doesn't free any page table. There may be race, 
but it sounds harmless IMHO.

> As for memory hotplug - ptdump already takes that lock in
> ptdump_walk_pgd() so you'd need to add that on split I think?

You mean mem_hotplug_lock, right? I don't recall memory hotplug takes 
mmap_lock. Did I miss something?

> So I think you need to take it in the split code and in
> arch_report_meminfo.
>
> So that solves that, you can get ptdump serialisation by ALSO taking the
> init_mm read map on split.

If I read your patch correctly, taking read mmap_lock in CPA is used to 
serialize between page table attributes change and page table collapse, 
right? We don't do page table collapse for linear mapping in ARM64 yet. 
There is ARM64 ROX cache patchset ongoing which added page table 
collapse, but the existing code doesn't.

Shall we serialize between split and ptdump by mmap_lock? Maybe, but it 
sounds harmless to me as I mentioned above.

Even though we take mmap_lock for split, it still can't protect linear 
mapping counter update between split and memory hotplug because memory 
hotplug doesn't take mmap_lock if my memory is correct. The linear 
mapping counter on x86 is protected by pgd_lock IIRC.

Thanks,
Yang

> That way you can rely on core ptdump stuff without having to add new
> locking in arm64-specific ptdump.
>
> And would you also need the pgtable_split_lock in arch_report_meminfo() to
> serialise lm_meminfo access?
>
> (Side-note: I am going to try to implement RCU kernel page table freeing at
> some point... so then maybe ptdump won't need the init_mm lock any
> more. But we could still take it there for this at least :)
>
> > Will
> Cheers, Lorenzo