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

[Anshuman Khandual]

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:
>>>> 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@xxxxxxx>
>>>>>
>>>>> [ 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.
Sure, will send out the change as suggested.