mm/migrate_device: fix cache flush when replacing huge zero PMD

[PATCH] mm/migrate_device: fix cache flush when replacing huge zero PMD

Posted by Hui Su 1 month, 1 week ago

migrate_vma_insert_huge_pmd_page() calls flush_cache_page() before
replacing an existing huge zero PMD. However, the third argument to
flush_cache_page() is a PFN, while addr + HPAGE_PMD_SIZE is an end
virtual address.

More importantly, the mapping being invalidated is PMD-sized rather
than PAGE_SIZE-sized. Flush the whole PMD range with
flush_cache_range(), matching other huge PMD invalidation paths.

Fixes: a30b48bf1b24 ("mm/migrate_device: implement THP migration of zone device pages")
Signed-off-by: Hui Su <sh_def@163.com>
---
 mm/migrate_device.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/migrate_device.c b/mm/migrate_device.c
index 908d2d4ec43a..098c04c1b124 100644
--- a/mm/migrate_device.c
+++ b/mm/migrate_device.c
@@ -872,7 +872,7 @@ static int migrate_vma_insert_huge_pmd_page(struct migrate_vma *migrate,
 
 	if (flush) {
 		pte_free(vma->vm_mm, pgtable);
-		flush_cache_page(vma, addr, addr + HPAGE_PMD_SIZE);
+		flush_cache_range(vma, addr, addr + HPAGE_PMD_SIZE);
 		pmdp_invalidate(vma, addr, pmdp);
 	} else {
 		pgtable_trans_huge_deposit(vma->vm_mm, pmdp, pgtable);
-- 
2.54.0

Re: [PATCH] mm/migrate_device: fix cache flush when replacing huge zero PMD

Posted by Zi Yan 1 month, 1 week ago

On Mon Aug 17, 2026 at 2:08 AM EDT, Hui Su wrote:
> migrate_vma_insert_huge_pmd_page() calls flush_cache_page() before
> replacing an existing huge zero PMD. However, the third argument to
> flush_cache_page() is a PFN, while addr + HPAGE_PMD_SIZE is an end
> virtual address.
>
> More importantly, the mapping being invalidated is PMD-sized rather
> than PAGE_SIZE-sized. Flush the whole PMD range with
> flush_cache_range(), matching other huge PMD invalidation paths.
>
> Fixes: a30b48bf1b24 ("mm/migrate_device: implement THP migration of zone device pages")
> Signed-off-by: Hui Su <sh_def@163.com>
> ---
>  mm/migrate_device.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>

Thank you for fixing it.

Reviewed-by: Zi Yan <ziy@nvidia.com>



-- 
Best Regards,
Yan, Zi

Re: [PATCH] mm/migrate_device: fix cache flush when replacing huge zero PMD

Posted by David Hildenbrand (Arm) 1 month, 1 week ago

On 8/17/26 18:39, Zi Yan wrote:
> On Mon Aug 17, 2026 at 2:08 AM EDT, Hui Su wrote:
>> migrate_vma_insert_huge_pmd_page() calls flush_cache_page() before
>> replacing an existing huge zero PMD. However, the third argument to
>> flush_cache_page() is a PFN, while addr + HPAGE_PMD_SIZE is an end
>> virtual address.
>>
>> More importantly, the mapping being invalidated is PMD-sized rather
>> than PAGE_SIZE-sized. Flush the whole PMD range with
>> flush_cache_range(), matching other huge PMD invalidation paths.
>>
>> Fixes: a30b48bf1b24 ("mm/migrate_device: implement THP migration of zone device pages")
>> Signed-off-by: Hui Su <sh_def@163.com>
>> ---
>>  mm/migrate_device.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
> 
> Thank you for fixing it.
> 
> Reviewed-by: Zi Yan <ziy@nvidia.com>

Acked-by: David Hildenbrand (Arm) <david@kernel.org>

I do wonder whether there should be a PMD helper.

-- 
Cheers,

David

Re: [PATCH] mm/migrate_device: fix cache flush when replacing huge zero PMD

Posted by Balbir Singh 1 month, 1 week ago

On 8/17/26 4:08 PM, Hui Su wrote:
> migrate_vma_insert_huge_pmd_page() calls flush_cache_page() before
> replacing an existing huge zero PMD. However, the third argument to
> flush_cache_page() is a PFN, while addr + HPAGE_PMD_SIZE is an end
> virtual address.
> 
> More importantly, the mapping being invalidated is PMD-sized rather
> than PAGE_SIZE-sized. Flush the whole PMD range with
> flush_cache_range(), matching other huge PMD invalidation paths.
> 
> Fixes: a30b48bf1b24 ("mm/migrate_device: implement THP migration of zone device pages")
> Signed-off-by: Hui Su <sh_def@163.com>
> ---
>  mm/migrate_device.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/mm/migrate_device.c b/mm/migrate_device.c
> index 908d2d4ec43a..098c04c1b124 100644
> --- a/mm/migrate_device.c
> +++ b/mm/migrate_device.c
> @@ -872,7 +872,7 @@ static int migrate_vma_insert_huge_pmd_page(struct migrate_vma *migrate,
>  
>  	if (flush) {
>  		pte_free(vma->vm_mm, pgtable);
> -		flush_cache_page(vma, addr, addr + HPAGE_PMD_SIZE);
> +		flush_cache_range(vma, addr, addr + HPAGE_PMD_SIZE);
>  		pmdp_invalidate(vma, addr, pmdp);
>  	} else {
>  		pgtable_trans_huge_deposit(vma->vm_mm, pmdp, pgtable);

Reviewed-by: Balbir Singh <balbirs@nvidia.com>

Re: [PATCH] mm/migrate_device: fix cache flush when replacing huge zero PMD

Posted by Andrew Morton 1 month, 1 week ago

On Mon, 17 Aug 2026 17:35:53 +1000 Balbir Singh <balbirs@nvidia.com> wrote:

> On 8/17/26 4:08 PM, Hui Su wrote:
> > migrate_vma_insert_huge_pmd_page() calls flush_cache_page() before
> > replacing an existing huge zero PMD. However, the third argument to
> > flush_cache_page() is a PFN, while addr + HPAGE_PMD_SIZE is an end
> > virtual address.
> > 
> > More importantly, the mapping being invalidated is PMD-sized rather
> > than PAGE_SIZE-sized. Flush the whole PMD range with
> > flush_cache_range(), matching other huge PMD invalidation paths.
> > 
> > Fixes: a30b48bf1b24 ("mm/migrate_device: implement THP migration of zone device pages")
> > Signed-off-by: Hui Su <sh_def@163.com>
> > ---
> >  mm/migrate_device.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/mm/migrate_device.c b/mm/migrate_device.c
> > index 908d2d4ec43a..098c04c1b124 100644
> > --- a/mm/migrate_device.c
> > +++ b/mm/migrate_device.c
> > @@ -872,7 +872,7 @@ static int migrate_vma_insert_huge_pmd_page(struct migrate_vma *migrate,
> >  
> >  	if (flush) {
> >  		pte_free(vma->vm_mm, pgtable);
> > -		flush_cache_page(vma, addr, addr + HPAGE_PMD_SIZE);
> > +		flush_cache_range(vma, addr, addr + HPAGE_PMD_SIZE);
> >  		pmdp_invalidate(vma, addr, pmdp);
> >  	} else {
> >  		pgtable_trans_huge_deposit(vma->vm_mm, pmdp, pgtable);
> 
> Reviewed-by: Balbir Singh <balbirs@nvidia.com>

doh.  It's a shame this actually compiled...

Can we add some speculation about the userspace-visible effects of the
bug?

I'm assuming we should backport the fix?

Re: [PATCH] mm/migrate_device: fix cache flush when replacing huge zero PMD

Posted by Hui Su 1 month, 1 week ago

> On Mon, 17 Aug 2026 17:35:53 +1000 Balbir Singh <balbirs@nvidia.com> wrote:
> 
> > On 8/17/26 4:08 PM, Hui Su wrote:
> > > migrate_vma_insert_huge_pmd_page() calls flush_cache_page() before
> > > replacing an existing huge zero PMD. However, the third argument to
> > > flush_cache_page() is a PFN, while addr + HPAGE_PMD_SIZE is an end
> > > virtual address.
> > > 
> > > More importantly, the mapping being invalidated is PMD-sized rather
> > > than PAGE_SIZE-sized. Flush the whole PMD range with
> > > flush_cache_range(), matching other huge PMD invalidation paths.
> > > 
> > > Fixes: a30b48bf1b24 ("mm/migrate_device: implement THP migration of zone device pages")
> > > Signed-off-by: Hui Su <sh_def@163.com>
> > > ---
> > >  mm/migrate_device.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/mm/migrate_device.c b/mm/migrate_device.c
> > > index 908d2d4ec43a..098c04c1b124 100644
> > > --- a/mm/migrate_device.c
> > > +++ b/mm/migrate_device.c
> > > @@ -872,7 +872,7 @@ static int migrate_vma_insert_huge_pmd_page(struct migrate_vma *migrate,
> > >  
> > >  	if (flush) {
> > >  		pte_free(vma->vm_mm, pgtable);
> > > -		flush_cache_page(vma, addr, addr + HPAGE_PMD_SIZE);
> > > +		flush_cache_range(vma, addr, addr + HPAGE_PMD_SIZE);
> > >  		pmdp_invalidate(vma, addr, pmdp);
> > >  	} else {
> > >  		pgtable_trans_huge_deposit(vma->vm_mm, pmdp, pgtable);
> > 
> > Reviewed-by: Balbir Singh <balbirs@nvidia.com>
> 
> doh.  It's a shame this actually compiled...
> 
> Can we add some speculation about the userspace-visible effects of the
> bug?
> 
> I'm assuming we should backport the fix?

Hi,

I took a closer look at this, there is no userspace-visible effect today.

The architectures that currently enable ARCH_ENABLE_THP_MIGRATION use
no-op implementations of flush_cache_page()/flush_cache_range().
32-bit ARM has non-trivial implementations, but does not enable
ARCH_ENABLE_THP_MIGRATION.

So this appears to be a latent API misuse rather than a currently
observable bug, and I don't think a stable backport is necessary.

Should I resend a v2 clarifying the userspace-visible effect in the
changelog?

Thanks,
Hui

Re: [PATCH] mm/migrate_device: fix cache flush when replacing huge zero PMD

Posted by Andrew Morton 1 month, 1 week ago

On Tue, 18 Aug 2026 00:36:46 +0800 Hui Su <sh_def@163.com> wrote:

> > > > --- a/mm/migrate_device.c
> > > > +++ b/mm/migrate_device.c
> > > > @@ -872,7 +872,7 @@ static int migrate_vma_insert_huge_pmd_page(struct migrate_vma *migrate,
> > > >  
> > > >  	if (flush) {
> > > >  		pte_free(vma->vm_mm, pgtable);
> > > > -		flush_cache_page(vma, addr, addr + HPAGE_PMD_SIZE);
> > > > +		flush_cache_range(vma, addr, addr + HPAGE_PMD_SIZE);
> > > >  		pmdp_invalidate(vma, addr, pmdp);
> > > >  	} else {
> > > >  		pgtable_trans_huge_deposit(vma->vm_mm, pmdp, pgtable);
> > > 
> > > Reviewed-by: Balbir Singh <balbirs@nvidia.com>
> > 
> > doh.  It's a shame this actually compiled...
> > 
> > Can we add some speculation about the userspace-visible effects of the
> > bug?
> > 
> > I'm assuming we should backport the fix?
> 
> Hi,
> 
> I took a closer look at this, there is no userspace-visible effect today.
> 
> The architectures that currently enable ARCH_ENABLE_THP_MIGRATION use
> no-op implementations of flush_cache_page()/flush_cache_range().
> 32-bit ARM has non-trivial implementations, but does not enable
> ARCH_ENABLE_THP_MIGRATION.
> 
> So this appears to be a latent API misuse rather than a currently
> observable bug, and I don't think a stable backport is necessary.

OK, thanks for checking.

> Should I resend a v2 clarifying the userspace-visible effect in the
> changelog?

Yes please, after 7.3-rc1.

Re: [PATCH] mm/migrate_device: fix cache flush when replacing huge zero PMD

Posted by Andrew Morton 1 month, 1 week ago

On Mon, 17 Aug 2026 14:34:15 -0700 Andrew Morton <akpm@linux-foundation.org> wrote:

> > Hi,
> > 
> > I took a closer look at this, there is no userspace-visible effect today.
> > 
> > The architectures that currently enable ARCH_ENABLE_THP_MIGRATION use
> > no-op implementations of flush_cache_page()/flush_cache_range().
> > 32-bit ARM has non-trivial implementations, but does not enable
> > ARCH_ENABLE_THP_MIGRATION.
> > 
> > So this appears to be a latent API misuse rather than a currently
> > observable bug, and I don't think a stable backport is necessary.
> 
> OK, thanks for checking.
> 
> > Should I resend a v2 clarifying the userspace-visible effect in the
> > changelog?
> 
> Yes please, after 7.3-rc1.

Actually, I updated the changelog and added it to next week's
queue-for-Linus.

Re: [PATCH] mm/migrate_device: fix cache flush when replacing huge zero PMD

Posted by Balbir Singh 1 month, 1 week ago

On 8/18/26 7:34 AM, Andrew Morton wrote:
> On Tue, 18 Aug 2026 00:36:46 +0800 Hui Su <sh_def@163.com> wrote:
> 
>>>>> --- a/mm/migrate_device.c
>>>>> +++ b/mm/migrate_device.c
>>>>> @@ -872,7 +872,7 @@ static int migrate_vma_insert_huge_pmd_page(struct migrate_vma *migrate,
>>>>>  
>>>>>  	if (flush) {
>>>>>  		pte_free(vma->vm_mm, pgtable);
>>>>> -		flush_cache_page(vma, addr, addr + HPAGE_PMD_SIZE);
>>>>> +		flush_cache_range(vma, addr, addr + HPAGE_PMD_SIZE);
>>>>>  		pmdp_invalidate(vma, addr, pmdp);
>>>>>  	} else {
>>>>>  		pgtable_trans_huge_deposit(vma->vm_mm, pmdp, pgtable);
>>>>
>>>> Reviewed-by: Balbir Singh <balbirs@nvidia.com>
>>>
>>> doh.  It's a shame this actually compiled...
>>>
>>> Can we add some speculation about the userspace-visible effects of the
>>> bug?
>>>
>>> I'm assuming we should backport the fix?
>>
>> Hi,
>>
>> I took a closer look at this, there is no userspace-visible effect today.
>>
>> The architectures that currently enable ARCH_ENABLE_THP_MIGRATION use
>> no-op implementations of flush_cache_page()/flush_cache_range().
>> 32-bit ARM has non-trivial implementations, but does not enable
>> ARCH_ENABLE_THP_MIGRATION.
>>
>> So this appears to be a latent API misuse rather than a currently
>> observable bug, and I don't think a stable backport is necessary.
> 
> OK, thanks for checking.
> 
>> Should I resend a v2 clarifying the userspace-visible effect in the
>> changelog?
> 
> Yes please, after 7.3-rc1.

I have been running some tests at my end, I have some new ones, nothing
so far exposes this. Thanks for checking Hui!

Balbir