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

[Greg Kroah-Hartman <gregkh@linuxfoundation.org>]

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:
> >> 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@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?
> 
> 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.

thanks,

greg k-h