All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Zi Yan" <ziy@nvidia.com>
To: "Andrew Morton" <akpm@linux-foundation.org>,
	"David Hildenbrand" <david@kernel.org>,
	"Matthew Brost" <matthew.brost@intel.com>,
	"Joshua Hahn" <joshua.hahnjy@gmail.com>,
	"Rakie Kim" <rakie.kim@sk.com>,
	"Byungchul Park" <byungchul@sk.com>,
	"Gregory Price" <gourry@gourry.net>,
	"Ying Huang" <ying.huang@linux.alibaba.com>,
	"Alistair Popple" <apopple@nvidia.com>,
	"Balbir Singh" <balbirs@nvidia.com>,
	"Kefeng Wang" <wangkefeng.wang@huawei.com>
Cc: <linux-mm@kvack.org>, <linux-kernel@vger.kernel.org>,
	"Sashiko" <sashiko-bot@kernel.org>, "Zi Yan" <ziy@nvidia.com>
Subject: Re: [PATCH] mm/migrate_device: avoid overflowing migrate_vma collection arrays
Date: Thu, 09 Jul 2026 22:54:02 -0400	[thread overview]
Message-ID: <DJUJVOIVLYL2.OMQEX12FKKH@nvidia.com> (raw)
In-Reply-To: <20260707-fix-array-overflow-in-migrate_vma_collect_pmd-v1-1-ce3ff4627653@nvidia.com>

On Tue Jul 7, 2026 at 9:50 PM EDT, Zi Yan wrote:
> migrate_vma_collect_pmd() can drop pte lock to split a large folio and
> restart. But the code does not handle restart properly when pmd becomes
> huge or cleared. It can overflow migrate->dst and migrate->src arrays
> during the hole or skip collection. Fix it by:
> 1. avoiding migrate_vma_collect_huge_pmd() if some collection is done,
> 2. skipping the rest of the range if pmd no longer points to a pte page
>    table.
>
> Fixes: a30b48bf1b244 ("mm/migrate_device: implement THP migration of zone device pages")
> Reported-by: Sashiko <sashiko-bot@kernel.org>
> Closes: https://sashiko.dev/#/patchset/20260706111958.3649651-1-wangkefeng.wang@huawei.com
> Assisted-by: Claude:claude-opus-4-8
> Signed-off-by: Zi Yan <ziy@nvidia.com>
> ---
> The issue is spot by Sashiko during a patch[1] review as a pre-existing one.
> This patch has the minimal change. An alternative is to reset
> migrate->cpages and migrate->npages and restart the whole range from the
> beginning, but that also requires a restoration of no-longer-present PTEs.
>
> Link: https://lore.kernel.org/all/20260706111958.3649651-1-wangkefeng.wang@huawei.com/ [1]
> ---
>  mm/migrate_device.c | 19 +++++++++++++++++--
>  1 file changed, 17 insertions(+), 2 deletions(-)
>

Sashiko has a new concern:

https://sashiko.dev/#/patchset/20260707-fix-array-overflow-in-migrate_vma_collect_pmd-v1-1-ce3ff4627653@nvidia.com

Q: migrate_vma_collect_pmd() drops the page table lock without flushing
the TLB leave stale entries active? When an order-0 page is collected and
its present PTE becomes a migration entry without flushing TLBs, later
CPUs with the stale TLB can still write to the page, potentially leading
to data corruption.

Answer: No, migrate_vma_collect_pmd() adds a reference to the collected
pages, so these pages are not going away. In addition, unmapped is
incremented after a page collection and warrants a TLB flush before the
code exits migrate_vma_collect_pmd():

1. pte_offset_map_lock() fails, this patch adds a flush.
2. split fails, a flush is already in the code.
3. the whole range is processed, a flush is at the end of the function.


-- 
Best Regards,
Yan, Zi


      parent reply	other threads:[~2026-07-10  2:54 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-08  1:50 [PATCH] mm/migrate_device: avoid overflowing migrate_vma collection arrays Zi Yan
2026-07-08  2:45 ` Balbir Singh
2026-07-08  8:43 ` David Hildenbrand (Arm)
2026-07-08 14:35   ` Zi Yan
2026-07-08 14:43     ` Zi Yan
2026-07-10 11:30       ` Zi Yan
2026-07-10 11:56         ` David Hildenbrand (Arm)
2026-07-10 15:35           ` Zi Yan
2026-07-13 12:57             ` David Hildenbrand (Arm)
2026-07-13 15:20               ` Zi Yan
2026-07-13 15:25                 ` David Hildenbrand (Arm)
2026-07-13 15:39                   ` Zi Yan
2026-07-13 22:24                     ` Alistair Popple
2026-07-14  0:10                       ` Balbir Singh
2026-07-14  5:30                         ` Alistair Popple
2026-07-10  2:54 ` Zi Yan [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DJUJVOIVLYL2.OMQEX12FKKH@nvidia.com \
    --to=ziy@nvidia.com \
    --cc=akpm@linux-foundation.org \
    --cc=apopple@nvidia.com \
    --cc=balbirs@nvidia.com \
    --cc=byungchul@sk.com \
    --cc=david@kernel.org \
    --cc=gourry@gourry.net \
    --cc=joshua.hahnjy@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=matthew.brost@intel.com \
    --cc=rakie.kim@sk.com \
    --cc=sashiko-bot@kernel.org \
    --cc=wangkefeng.wang@huawei.com \
    --cc=ying.huang@linux.alibaba.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.