From: sashiko-bot@kernel.org
To: "Matthew Brost" <matthew.brost@intel.com>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 2/4] mm/migrate_device: Apply the fault reference to the correct folio
Date: Wed, 05 Aug 2026 11:54:41 +0000 [thread overview]
Message-ID: <20260805115442.4CA2E1F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <20260805113338.3742178-3-matthew.brost@intel.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
Pre-existing issues:
- [Critical] Error paths in `__migrate_device_pages` after a successful THP split fail to clear `MIGRATE_PFN_MIGRATE` on tail pages, leading to uninitialized device memory being mapped into userspace.
- [High] `folio_free_swap()` is only called on the head folio after splitting a swap-backed THP, leaving tail folios improperly in the swap cache.
--
--- Patch [2]: [PATCH 2/4] mm/migrate_device: Apply the fault reference to the correct folio ---
commit 4d89d00fc35f8db7c498dd86850a797d2e8c3d2b
Author: Matthew Brost <matthew.brost@intel.com>
mm/migrate_device: Apply the fault reference to the correct folio
This commit fixes a bug in __migrate_device_pages() where extra_cnt was
calculated once for the head page and incorrectly applied to all sub-folios
during a THP migration split. It moves the extra_cnt calculation inside the
sub-folio loop so that the CPU fault reference is correctly applied only to
the sub-folio containing the fault page.
> diff --git a/mm/migrate_device.c b/mm/migrate_device.c
> index bf8d21857d380..5b078fcbec792 100644
> --- a/mm/migrate_device.c
> +++ b/mm/migrate_device.c
> @@ -1201,7 +1201,7 @@ static void __migrate_device_pages(unsigned long *src_pfns,
> struct page *page = migrate_pfn_to_page(src_pfns[i]);
> struct address_space *mapping;
> struct folio *newfolio, *folio;
> - int r, extra_cnt = 0;
> + int r;
> unsigned long nr = 1;
>
> if (!newpage) {
[ ... ]
> @@ -1306,13 +1306,25 @@ static void __migrate_device_pages(unsigned long *src_pfns,
>
> BUG_ON(folio_test_writeback(folio));
>
[Severity: High]
This is a pre-existing issue, but does calling folio_free_swap() only on the
head page leave the tail pages in the swap cache?
If a swap-backed THP is split into order-0 folios by
migrate_vma_split_unmapped_folio() in __migrate_device_pages(), the local
"folio" variable still points to the head page. The code just before this
BUG_ON() calls:
if (mapping) {
if (!folio_test_anon(folio) ||
!folio_free_swap(folio)) {
Because this is outside the subpage loop, it only removes the head page from
the swap cache. Later in the loop, when folio_migrate_mapping() is called
for the tail pages, could they still be marked as swap cache and incorrectly
replace their swap cache entries with device private pages?
[Severity: Critical]
This is a pre-existing issue, but do the error paths after a THP split fail to
clear MIGRATE_PFN_MIGRATE on tail pages?
If the destination only allocates order-0 pages and the THP is successfully
split in __migrate_device_pages(), the MIGRATE_PFN_MIGRATE flag is active on
all tail pages in src_pfns. If a subsequent check fails, the code just before
this BUG_ON() does:
if (!folio_test_anon(folio) ||
!folio_free_swap(folio)) {
src_pfns[i] &= ~MIGRATE_PFN_MIGRATE;
goto next;
}
} else if (folio_is_zone_device(newfolio)) {
src_pfns[i] &= ~MIGRATE_PFN_MIGRATE;
goto next;
}
This clears the flag for the head page (src_pfns[i]), but not the tail pages.
Since the loop advances by "nr" at the "next" label, the tail pages keep their
migration flag. Could __migrate_device_finalize() then mistakenly assume they
migrated successfully and map uninitialized device memory into userspace?
> - if (migrate && migrate->fault_page == page)
> - extra_cnt = 1;
> for (j = 0; j < nr && i + j < npages; j++) {
> - folio = page_folio(migrate_pfn_to_page(src_pfns[i+j]));
> + struct page *src_page = migrate_pfn_to_page(src_pfns[i+j]);
> + int extra_cnt = 0;
> +
> + folio = page_folio(src_page);
> newfolio = page_folio(migrate_pfn_to_page(dst_pfns[i+j]));
>
> - r = folio_migrate_mapping(mapping, newfolio, folio, extra_cnt);
> + /*
> + * The CPU fault holds an extra reference on the folio
> + * containing the fault page. @folio may have been
> + * split above, so the fault page only accounts for an
> + * extra reference on the folio it actually ended up
> + * in, not on every folio of the original THP.
> + */
> + if (migrate && migrate->fault_page == src_page)
> + extra_cnt = 1;
> +
> + r = folio_migrate_mapping(folio_mapping(folio), newfolio,
> + folio, extra_cnt);
> if (r)
> src_pfns[i+j] &= ~MIGRATE_PFN_MIGRATE;
> else
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260805113338.3742178-1-matthew.brost@intel.com?part=2
next prev parent reply other threads:[~2026-08-05 11:54 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-05 11:33 [PATCH 0/4] Fix device page migration in low memory fallback Matthew Brost
2026-08-05 11:33 ` [PATCH 1/4] mm/migrate_device: Fix THP splitting of a CPU faulted device private folio Matthew Brost
2026-08-05 11:33 ` [PATCH 2/4] mm/migrate_device: Apply the fault reference to the correct folio Matthew Brost
2026-08-05 11:54 ` sashiko-bot [this message]
2026-08-05 11:33 ` [PATCH 3/4] drm/pagemap: Fix folio allocation fallback and use-after-put Matthew Brost
2026-08-05 11:47 ` sashiko-bot
2026-08-05 11:33 ` [PATCH 4/4] drm/pagemap: Add fault injection for higher-order RAM folio allocation Matthew Brost
2026-08-05 11:51 ` sashiko-bot
2026-08-05 15:22 ` ✗ CI.checkpatch: warning for Fix device page migration in low memory fallback Patchwork
2026-08-05 15:23 ` ✓ CI.KUnit: success " Patchwork
2026-08-05 15:59 ` ✓ Xe.CI.BAT: " Patchwork
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=20260805115442.4CA2E1F00A3A@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=matthew.brost@intel.com \
--cc=sashiko-reviews@lists.linux.dev \
/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.