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

[Will Deacon]

On Thu, Jun 25, 2026 at 07:59:51AM +0530, Anshuman Khandual wrote:
> On 24/06/26 9:59 PM, Greg Kroah-Hartman wrote:
> > On Wed, Jun 24, 2026 at 04:05:01PM +0100, Ryan Roberts wrote:
> >> On 23/06/2026 15:25, Will Deacon wrote:
> >>> On Sun, Jun 21, 2026 at 05:02:27PM +0200, Ben Hutchings wrote:
> >>>>> @@ -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?
> >>
> >> I think this change was probably my fault; Given the API is called
> >> flush_tlb_kernel_range() it seemed like an abuse/hack to pretend we are only
> >> flushing the first PAGE_SIZE of the range. But as I understand it, even if the
> >> HW shatters a block mapping into multiple TLB entries, all of the entries
> >> relating to the block mapping will be invalidated if just one of them intersects
> >> the TLBI range/address. So it should be safe to reapply this hack.
> >>
> >> Although ideally I think it would be better if this API took a stride argument;
> >> then intent is clear.
> >>
> >> What's the best way to handle this? Submit a patch for mainline that reverts
> >> this part, then get it backported to stable (implying this current patch will
> >> have been applied to stable)?
> > 
> > yes, that's probably the best way.
> Sure, will send out the change as suggested.

In case anybody ends up following the breadcrumbs, the patch is here:

https://lore.kernel.org/r/20260626012845.475959-1-anshuman.khandual@xxxxxxx

Will