Re: [v8 PATCH] arm64: mm: show direct mapping use in /proc/meminfo
From: Will Deacon
Date: Tue Jul 28 2026 - 05:35:02 EST
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.
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.
Will