From: sashiko-bot@kernel.org
To: "Matthew Brost" <matthew.brost@intel.com>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v2 2/5] mm/migrate_device: Fix THP splitting of a CPU faulted device private folio
Date: Wed, 05 Aug 2026 20:34:34 +0000 [thread overview]
Message-ID: <20260805203435.121601F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260805193536.3756457-3-matthew.brost@intel.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Out-of-bounds write in `migrate_device_range()` and `migrate_device_pfns()` when processing compound device private folios.
--
--- Patch [2]: [PATCH v2 2/5] mm/migrate_device: Fix THP splitting of a CPU faulted device private folio ---
commit 66cc9eb01f0258173048c3a225ebb9ca65d56410
Author: Matthew Brost <matthew.brost@intel.com>
mm/migrate_device: Fix THP splitting of a CPU faulted device private folio
This commit fixes two issues when splitting a device private THP during a CPU
fault: it drops and re-acquires the fault reference across the split to prevent
it from failing, and walks the rmap to demote all PMD sized migration entries
before splitting to prevent leaving stale huge PMDs in other VMAs.
[ ... ]
> diff --git a/mm/migrate_device.c b/mm/migrate_device.c
> index 1e24039f62b33..155a182c528f8 100644
> --- a/mm/migrate_device.c
> +++ b/mm/migrate_device.c
> @@ -1187,8 +1268,7 @@ static void __migrate_device_pages(unsigned long *src_pfns,
> goto next;
> }
> nr = 1 << folio_order(folio);
> - addr = migrate->start + i * PAGE_SIZE;
> - if (migrate_vma_split_unmapped_folio(migrate, i, addr, folio)) {
> + if (migrate_vma_split_unmapped_folio(migrate, i, folio)) {
> src_pfns[i] &= ~(MIGRATE_PFN_MIGRATE |
> MIGRATE_PFN_COMPOUND);
> goto next;
[Severity: High]
This is a pre-existing issue, but does migrate_device_range() write out of
bounds when processing a compound device private folio?
Looking at mm/migrate_device.c:migrate_device_range(), the code iterates
through pfns:
for (pfn = start, i = 0; i < npages; pfn++, i++) {
...
nr = folio_nr_pages(folio);
if (nr > 1) {
src_pfns[i] |= MIGRATE_PFN_COMPOUND;
for (j = 1; j < nr; j++)
src_pfns[i+j] = 0;
i += j - 1;
pfn += j - 1;
}
}
If npages does not fully cover the compound folio, this loop writes zeroes
into src_pfns without checking if i + j is less than npages. Because
src_pfns is allocated by the caller to exactly npages in size, writing up
to nr - 1 zeroes can overflow the array.
The exact same missing bounds check appears in migrate_device_pfns():
for (i = 0; i < npages; i++) {
...
nr = folio_nr_pages(folio);
if (nr > 1) {
src_pfns[i] |= MIGRATE_PFN_COMPOUND;
for (j = 1; j < nr; j++)
src_pfns[i+j] = 0;
i += j - 1;
}
}
Could these loops be updated to check i + j < npages before writing?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260805193536.3756457-1-matthew.brost@intel.com?part=2
next prev parent reply other threads:[~2026-08-05 20:34 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-05 19:35 [PATCH v2 0/5] Fix device page migration in low memory fallback Matthew Brost
2026-08-05 19:35 ` [PATCH v2 1/5] mm/migrate_device: Clear MIGRATE_PFN_MIGRATE on all sub-folios of a split THP Matthew Brost
2026-08-05 20:15 ` sashiko-bot
2026-08-05 19:35 ` [PATCH v2 2/5] mm/migrate_device: Fix THP splitting of a CPU faulted device private folio Matthew Brost
2026-08-05 20:34 ` sashiko-bot [this message]
2026-08-05 19:35 ` [PATCH v2 3/5] mm/migrate_device: Apply the fault reference to the correct folio Matthew Brost
2026-08-05 20:50 ` sashiko-bot
2026-08-05 19:35 ` [PATCH v2 4/5] drm/pagemap: Fix folio allocation fallback and use-after-put Matthew Brost
2026-08-05 19:35 ` [PATCH v2 5/5] drm/pagemap: Add fault injection for higher-order RAM folio allocation Matthew Brost
2026-08-05 21:07 ` sashiko-bot
2026-08-05 19:42 ` ✗ CI.checkpatch: warning for Fix device page migration in low memory fallback (rev2) Patchwork
2026-08-05 19:43 ` ✓ CI.KUnit: success " Patchwork
2026-08-05 20:19 ` ✓ 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=20260805203435.121601F000E9@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.