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

["Lorenzo Stoakes (ARM)" <ljs@kernel.org>]

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@kernel.org/
> >
> > 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.
>
> 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.

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

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.

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