From: "David Hildenbrand (Arm)" <david@kernel.org>
To: Hui Su <sh_def@163.com>, Andrew Morton <akpm@linux-foundation.org>
Cc: Balbir Singh <balbirs@nvidia.com>,
Matthew Brost <matthew.brost@intel.com>, Zi Yan <ziy@nvidia.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>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3] mm/migrate_device: consolidate compound folio handling
Date: Wed, 23 Sep 2026 15:49:27 +0200 [thread overview]
Message-ID: <60634ab5-3fcc-42fb-8722-4ba6771acfda@kernel.org> (raw)
In-Reply-To: <20260923112041.2103427-1-sh_def@163.com>
On 9/23/26 13:20, Hui Su wrote:
> Commit dc41e961a269 ("mm/migrate_device: avoid out-of-bounds writes for
> compound folios") added handling for compound folios that do not fit in
> the remaining PFN array.
>
> migrate_device_range() and migrate_device_pfns() duplicate the logic for
> locking device PFNs, encoding compound folios, and handling this boundary
> condition.
>
> A compound folio cannot be represented partially for migration. Use
> VM_WARN_ON_ONCE() when one does not fit in the remaining PFN array, while
> retaining the existing defensive handling: release any lock and reference
> acquired for the current folio, clear the remaining entries, and stop
> collecting.
>
> Move the shared collection and encoding logic into a helper so both
> interfaces handle compound folios consistently. Also use memset() for the
> compound-folio tail entries instead of open-coding the clearing loop.
>
> If locking a folio fails, leave its source entry zero while still consuming
> and clearing the slots belonging to the whole folio. This prevents a tail
> page from being treated as a new source PFN by the caller's next iteration.
>
> Document that an encountered compound folio must fit entirely in the
> remaining range or PFN array.
>
> Link: https://lore.kernel.org/r/c99ca53a-73ef-4a0c-8738-eba1cc89bea2@kernel.org
> Suggested-by: David Hildenbrand <david@kernel.org>
> Acked-by: Balbir Singh <balbirs@nvidia.com>
> Signed-off-by: Hui Su <sh_def@163.com>
> ---
>
> Changes in v3:
> - Keep the source entry zero when migrate_device_pfn_lock() fails instead
> of setting MIGRATE_PFN_COMPOUND, while still consuming and clearing all
> slots belonging to the compound folio.
> - Use VM_WARN_ON_ONCE() for the truncated compound-folio invariant while
> keeping the defensive clear-and-stop path independent of CONFIG_DEBUG_VM,
> as suggested by Balbir Singh.
>
> Changes in v2:
> - Fix the helper parameter indentation and keep the declaration to two
> lines, as suggested by David Hildenbrand.
>
> mm/migrate_device.c | 91 +++++++++++++++++++++++++--------------------
> 1 file changed, 50 insertions(+), 41 deletions(-)
>
> diff --git a/mm/migrate_device.c b/mm/migrate_device.c
> index 009bfa8b212d..68b787bdc8be 100644
> --- a/mm/migrate_device.c
> +++ b/mm/migrate_device.c
> @@ -1392,6 +1392,40 @@ static unsigned long migrate_device_pfn_lock(unsigned long pfn)
> return migrate_pfn(pfn) | MIGRATE_PFN_MIGRATE;
> }
>
> +/*
> + * Collect a device folio into the page-granular PFN array.
> + *
> + * Return the number of entries consumed, or 0 if the folio does not fit in
> + * the remaining array.
> + */
> +static unsigned int migrate_device_collect_folio(unsigned long *src_pfn,
> + unsigned long pfn, unsigned long remaining)
> +{
> + struct folio *folio = page_folio(pfn_to_page(pfn));
> + unsigned int nr;
> +
> + *src_pfn = migrate_device_pfn_lock(pfn);
Let's rant about migrate_device_pfn_lock().
It looks up a folio (which we do as well !?) to then get+lock that folio, but
doesn't tell us about the folio, but we're supposed to magically unlock and put
that folio on the backout path?.
And if it fails (e.g., folio_get_nontail_page() failed) we simply go ahead and
work on that folio (folio_nr_pages() etc)?
What?!
Now that we have a single caller of migrate_device_pfn_lock(), can we please get
rid of this abomination and figure out what to do when migrate_device_pfn_lock()
would have returned 0?
> + nr = folio_nr_pages(folio);
> +
> + VM_WARN_ON_ONCE(nr > remaining);
> + if (nr > remaining) {
It's odd to add recovery paths for something that is mostly an internal
assertion. The pattern is odd.
I'd either
if (WARN_ON_ONCE(nr > remaining)) {
...
}
Or only do the VM_WARN_ON_ONCE() and drop recovery, expecting this to be found
early during testing.
> + if (*src_pfn & MIGRATE_PFN_MIGRATE) {
> + folio_unlock(folio);
> + folio_put(folio);
> + }
> + memset(src_pfn, 0, remaining * sizeof(*src_pfn));
> + return 0;
> + }
> +
> + if (nr > 1) {
> + if (*src_pfn)
> + *src_pfn |= MIGRATE_PFN_COMPOUND;
> + memset(src_pfn + 1, 0, (nr - 1) * sizeof(*src_pfn));
> + }
> +
> + return nr;
> +}
--
Cheers,
David
prev parent reply other threads:[~2026-09-23 13:49 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-23 11:20 [PATCH v3] mm/migrate_device: consolidate compound folio handling Hui Su
2026-09-23 13:49 ` David Hildenbrand (Arm) [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=60634ab5-3fcc-42fb-8722-4ba6771acfda@kernel.org \
--to=david@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=apopple@nvidia.com \
--cc=balbirs@nvidia.com \
--cc=byungchul@sk.com \
--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=sh_def@163.com \
--cc=ying.huang@linux.alibaba.com \
--cc=ziy@nvidia.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.