From: sashiko-bot@kernel.org
To: "Matthew Brost" <matthew.brost@intel.com>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v3 1/6] mm/migrate_device: Clear stale mapping after freeing swapcache
Date: Wed, 05 Aug 2026 23:22:50 +0000 [thread overview]
Message-ID: <20260805232251.4F7F31F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260805231041.3791771-2-matthew.brost@intel.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Missing `goto next;` causes aborted migration to corrupt page cache and page tables.
--
--- Patch [1]: [PATCH v3 1/6] mm/migrate_device: Clear stale mapping after freeing swapcache ---
commit 36bc19904d5fb8100fc812248c9247ad225d6ebe
Author: Arvind Yadav <arvind.yadav@intel.com>
mm/migrate_device: Clear stale mapping after freeing swapcache
This commit fixes a bug in __migrate_device_pages() where a stale mapping
is used after a folio is removed from the swap cache. It refreshes the
mapping via folio_mapping() and resets 'nr' to 1 after a successful folio
split to process the resulting order-0 folios independently.
> diff --git a/mm/migrate_device.c b/mm/migrate_device.c
> --- a/mm/migrate_device.c
> +++ b/mm/migrate_device.c
> @@ -1193,6 +1193,13 @@ static void __migrate_device_pages(unsigned long *src_pfns,
> MIGRATE_PFN_COMPOUND);
> goto next;
> }
> +
> + /*
> + * reset nr so that only first after-split folio
> + * is processed below
> + */
> + VM_WARN_ON_ONCE(folio_test_large(folio));
> + nr = 1;
> } else if ((src_pfns[i] & MIGRATE_PFN_MIGRATE) &&
> (dst_pfns[i] & MIGRATE_PFN_COMPOUND) &&
> !(src_pfns[i] & MIGRATE_PFN_COMPOUND)) {
> src_pfns[i] &= ~MIGRATE_PFN_MIGRATE;
[Severity: High]
This is a pre-existing issue, but does this error path in
__migrate_device_pages() miss a goto next statement?
When a non-compound source page is paired with a compound destination page,
the code correctly clears the MIGRATE_PFN_MIGRATE flag to abort the
migration, but it falls through instead of skipping to the next iteration.
Without a goto next, execution continues to the unconditional page cache
migration loop at the bottom of the function. This calls
folio_migrate_mapping(), which moves the page cache state to the new folio.
Later, because MIGRATE_PFN_MIGRATE was cleared, migrate_vma_finalize() will
restore the CPU page tables to map the old source page. Will this cause data
corruption by desynchronizing the CPU page tables from the page cache?
> }
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260805231041.3791771-1-matthew.brost@intel.com?part=1
next prev parent reply other threads:[~2026-08-05 23:22 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-05 23:10 [PATCH v3 0/6] Fix device page migration in low memory fallback Matthew Brost
2026-08-05 23:10 ` [PATCH v3 1/6] mm/migrate_device: Clear stale mapping after freeing swapcache Matthew Brost
2026-08-05 23:22 ` sashiko-bot [this message]
2026-08-05 23:10 ` [PATCH v3 2/6] mm/migrate_device: Do not write past the end of the src_pfns array Matthew Brost
2026-08-05 23:25 ` sashiko-bot
2026-08-05 23:29 ` Balbir Singh
2026-08-05 23:10 ` [PATCH v3 3/6] mm/migrate_device: Fix THP splitting of a CPU faulted device private folio Matthew Brost
2026-08-06 8:10 ` Balbir Singh
2026-08-10 2:26 ` Huang, Ying
2026-08-10 19:43 ` Matthew Brost
2026-08-05 23:10 ` [PATCH v3 4/6] drm/pagemap: dma-unmap pages before handling migration errors Matthew Brost
2026-08-05 23:22 ` sashiko-bot
2026-08-05 23:10 ` [PATCH v3 5/6] drm/pagemap: Fix folio allocation fallback and use-after-put Matthew Brost
2026-08-05 23:10 ` [PATCH v3 6/6] drm/pagemap: Add fault injection for higher-order RAM folio allocation Matthew Brost
2026-08-05 23:24 ` sashiko-bot
2026-08-05 23:17 ` ✗ CI.checkpatch: warning for Fix device page migration in low memory fallback (rev3) Patchwork
2026-08-05 23:18 ` ✓ CI.KUnit: success " Patchwork
2026-08-06 0:02 ` ✓ Xe.CI.BAT: " Patchwork
2026-08-06 9:15 ` ✓ Xe.CI.FULL: " 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=20260805232251.4F7F31F000E9@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.