[PATCH 6.1 337/522] arm64/mm: Enable batched TLB flush in unmap_hotplug_range()

[Will Deacon]

On Sun, Jun 21, 2026 at 05:02:27PM +0200, Ben Hutchings wrote:
> On Tue, 2026-06-16 at 20:28 +0530, Greg Kroah-Hartman wrote:
> > 6.1-stable review patch.  If anyone has any objections, please let me know.
> > 
> > ------------------
> > 
> > From: Anshuman Khandual <anshuman.khandual at arm.com>
> > 
> > [ Upstream commit 48478b9f791376b4b89018d7afdfd06865498f65 ]
> [...]
> > @@ -949,15 +953,14 @@ static void unmap_hotplug_pmd_range(pud_
> >  		WARN_ON(!pmd_present(pmd));
> >  		if (pmd_sect(pmd)) {
> >  			pmd_clear(pmdp);
> > -
> > -			/*
> > -			 * One TLBI should be sufficient here as the PMD_SIZE
> > -			 * range is mapped with a single block entry.
> > -			 */
> > -			flush_tlb_kernel_range(addr, addr + PAGE_SIZE);
> > -			if (free_mapped)
> > +			if (free_mapped) {
> > +				/* CONT blocks are not supported in the vmemmap */
> > +				WARN_ON(pmd_cont(pmd));
> > +				flush_tlb_kernel_range(addr, addr + PMD_SIZE);
> 
> It wasn't clear to me from the commit message why this now adds PMD_SIZE
> rather than PAGE_SIZE.  It seems like this change is fine for Linux
> 6.13+ with a CPU that supports TLB range flushing, but otherwise results
> in unnecessarily executing multiple TLB invalidations at intervals of
> the base page size.

Hmm, the commit message also makes very little sense to me and so I don't
understand why this patch has us doing multiple TLB invalidations when
we run into a !cont, block mapping at the PMD level. The old comment
(which this patch removes) should still apply afaict.

Anshuman, Ryan, any ideas what's going on here?

Will