All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthew Brost <matthew.brost@intel.com>
To: intel-xe@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: [PATCH v2 0/5] Fix device page migration in low memory fallback
Date: Wed,  5 Aug 2026 12:35:31 -0700	[thread overview]
Message-ID: <20260805193536.3756457-1-matthew.brost@intel.com> (raw)

LLMs made my breakfast, lunch, and dinner. Not really. They served as an
assistive tool while I performed the debugging, testing, and analysis
needed to isolate the root cause in core MM while fixing a known DRM SVM
issue involving THP allocation failures in the CPU fault-to-device page
migration path.

When a CPU faults on a device private PMD and the driver cannot allocate
a compound destination folio, the source THP has to be split. That path
is broken: the CPU fault reference makes the split always fail, and it
demotes the PMD only in the faulting VMA, leaving any other VMA mapping
the folio pointing a huge PMD at an order-0 page.
The latter is memory corruption, previously masked by the former.

The DRM side had its own problems in the same fallback: there was no
order-0 fallback at all despite a TODO saying one was needed, the error
path computed folio_order() after put_page(), and once the destination
is demoted to order-0 the source page array has to be populated per
page rather than per folio head, or the copy stops after one page.

Validation was performed using xe_exec_system_allocator. The issue was
initially discovered on systems configured with an artificially
constrained memory footprint (mem=8G), where failures occurred
intermittently. Error injection was then introduced to reliably
reproduce the failure condition, enabling thorough validation of the
fix. Results were confirmed through pass/fail A/B testing.

Matt

v2::
 - Add assert in 'Fix folio allocation fallback and use-after-put' for
   THP placement invariant which Sashiko hallucinated as a bug [1]
 - Add 'Clear MIGRATE_PFN_MIGRATE on all sub-folios of a split THP'
   (Sashiko)
 - Fix checkpatch issues (CI)
 - Swap cache issue flagged by Sashiko [1] not fixed as this code doesn't
   appear reachable (i.e., dead code). Can address in a follow up if
   needed

[1] https://sashiko.dev/#/patchset/20260805113338.3742178-1-matthew.brost%40intel.com

Matthew Brost (5):
  mm/migrate_device: Clear MIGRATE_PFN_MIGRATE on all sub-folios of a
    split THP
  mm/migrate_device: Fix THP splitting of a CPU faulted device private
    folio
  mm/migrate_device: Apply the fault reference to the correct folio
  drm/pagemap: Fix folio allocation fallback and use-after-put
  drm/pagemap: Add fault injection for higher-order RAM folio allocation

 drivers/gpu/drm/drm_pagemap.c | 164 ++++++++++++++++++++++++++++------
 mm/migrate_device.c           | 129 ++++++++++++++++++++++----
 2 files changed, 251 insertions(+), 42 deletions(-)

-- 
2.34.1



             reply	other threads:[~2026-08-05 19:35 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-05 19:35 Matthew Brost [this message]
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
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=20260805193536.3756457-1-matthew.brost@intel.com \
    --to=matthew.brost@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    /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.