From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id F32293DC4D9 for ; Wed, 5 Aug 2026 19:35:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.9 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785958545; cv=none; b=e2hKX+Bv+AyJWN/2IezmBO5/Y/dLY5DLlpz80dOqWXsO3iXFWGGx7Kr50lrV06iltgweCBibIYVPveA8Bd0A7wM74BVpwBjoU2OQnn8pSNfTaOpZfRNGS/fnYEOFSxRbwO0gnDwH6d2sKNvSO5xpS51JCn99o7ga3XJd+m4W6dg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785958545; c=relaxed/simple; bh=sDSmB04u7511d8QYCqjiDsa689yH07QzsyscRbCuKVs=; h=From:To:Subject:Date:Message-Id:MIME-Version:Content-Type; b=uCW5yLnIOIj4diys7gMdhkjfbKwDw+iW60vyf6qLvFbRY5thMo1I49+hGMrYvw7f5F/SpTmsxAymHmLhhRrYglalVF9VmJ6bgXvCgZtDrRxnoiCaR1vmK9qZmupL0eUlUZXDIxoWNK7r1pXfI1EGYa6kZ2tYWLcS9m8l6Ene7+0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=TovmKB2V; arc=none smtp.client-ip=198.175.65.9 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="TovmKB2V" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1785958543; x=1817494543; h=from:to:subject:date:message-id:mime-version: content-transfer-encoding; bh=sDSmB04u7511d8QYCqjiDsa689yH07QzsyscRbCuKVs=; b=TovmKB2VHCZCrwPoVBq/yp+gMrRg/cuqfl5aWOycbnAXRirG88PbAJly arWZzTPHLB0xeJlhUHl3zgPQmX2E8Rvg1DRWlmSSvKUjGSAr9xgA0C5tL UwTmpI1fFUnx6IR+wXV42nZI+VEzrSKU1LpUl4LZoqh0t0uWEnZo5BDSv i7qIzQUlCXQ2E5zRA4SW8iF7i+ky+4RIA21pKdYK+1JAXOaDfXcVsle4/ XIHxY5Cr0xWGYQWyKt4aacePBgqn+DgQ+xZd5ul9bcTOmIunNpowYwtEh fwJT2OXFxKbmJpYP2g9Rb78UsZaIbYkQbng38kbl8ybzY5O66+id1+MS2 g==; X-CSE-ConnectionGUID: I31jtIeOTkOFmaZZpj38Mw== X-CSE-MsgGUID: 07iZy5GqSmCrsclWBBNSVg== X-IronPort-AV: E=McAfee;i="6800,10657,11866"; a="109332916" X-IronPort-AV: E=Sophos;i="6.25,207,1779174000"; d="scan'208";a="109332916" Received: from fmviesa002.fm.intel.com ([10.60.135.142]) by orvoesa101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Aug 2026 12:35:42 -0700 X-CSE-ConnectionGUID: wi5TCODVRw2LpdBi1XBMNA== X-CSE-MsgGUID: iFC1GBGTRZ6KFQ5eCCRW/A== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.25,207,1779174000"; d="scan'208";a="285263511" Received: from gsse-cloud1.jf.intel.com ([10.54.39.91]) by fmviesa002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Aug 2026 12:35:42 -0700 From: Matthew Brost 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 Message-Id: <20260805193536.3756457-1-matthew.brost@intel.com> X-Mailer: git-send-email 2.34.1 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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