From: Lance Yang <lance.yang@linux.dev>
To: akpm@linux-foundation.org
Cc: gourry@gourry.net, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, kernel-team@meta.com,
david@kernel.org, ljs@kernel.org, ziy@nvidia.com,
baolin.wang@linux.alibaba.com, liam@infradead.org,
nico.pache@linux.dev, ryan.roberts@arm.com, dev.jain@arm.com,
baohua@kernel.org, usama.arif@linux.dev, vbabka@kernel.org,
jannh@google.com, matthew.brost@intel.com,
joshua.hahnjy@gmail.com, rakie.kim@sk.com, byungchul@sk.com,
ying.huang@linux.alibaba.com, apopple@nvidia.com,
balbirs@nvidia.com, Lance Yang <lance.yang@linux.dev>
Subject: Re: [PATCH v2 0/3] mm: reject zone device folios in more folio walkers
Date: Sun, 30 Aug 2026 15:47:51 +0800 [thread overview]
Message-ID: <20260830074751.25370-1-lance.yang@linux.dev> (raw)
In-Reply-To: <c2577ec5-acf6-466b-ba66-0b3bcabbef7d@linux.dev>
On Sun, Aug 30, 2026 at 01:18:24PM +0800, Lance Yang wrote:
>
>
>On 2026/8/30 08:18, Andrew Morton wrote:
>> On Tue, 18 Aug 2026 12:31:43 +0800 Lance Yang <lance.yang@linux.dev> wrote:
>>
>>>
>>> On Mon, Aug 17, 2026 at 06:08:07PM -0400, Gregory Price wrote:
>>>> Several LRU-oriented mm walkers resolve the folio backing a PMD entry
>>>> (or a physical pfn) and then reclaim, age, migrate, or lazyfree it
>>>> without ever checking for ZONE_DEVICE memory.
>>>>
>>>> This series adds missing folio_is_zone_device() rejections, matching
>>>> the checks that comparable walkers already perform.
>>>>
>>>> - mm/huge_memory, mm/madvise: the !pmd_present branch above these sites
>>>> only filters device-private entries (which are non-present).
>>>>
>>>> A present zone device PMD (e.g. device-coherent) would still reach the
>>>> folio and be lazyfreed / aged / paged out. Add an explicit check.
>>>>
>>>> - mm/mempolicy: queue_folios_pmd() can see a present zone device PMD
>>>> (e.g. device-coherent) and queue it for migration.
>>>>
>>>> No crash reproducer - this is a correctness/hardening cleanup found by
>>>> inspection. All checks are placed after the folio is resolved and before
>>>> it is acted upon, on paths that already hold the relevant page-table lock,
>>>> so no locking or refcount changes are involved.
>>>
>>> Cool!
>>>
>>> Gave the whole series a spin on x86_64 QEMU with a PMD-mapped
>>> device-coherent THP. Without these patches, partial MADV_FREE and
>>> MADV_COLD reliably hit a kernel panic in remove_migration_pte(), while
>>> mbind(MPOL_MF_MOVE | MPOL_MF_STRICT) returned -EIO.
>>>
>>> With v2, all three worked fine, PMD mapping stayed intact, and data
>>> checked out :)
>>>
>>> Note that both kernels used the same small change to the in-kernel HMM
>>> test driver, allowing its coherent device memory to be allocated as 2 MB
>>> folios so the PMD-mapped test case could be exercised.
>>>
>>> Tested-by: Lance Yang <lance.yang@linux.dev>
>>
>> Thanks Lance, you're so diligent.
>>
>> I'm wondering what to do here. Gregory told us
>>
>> : No crash reproducer - this is a correctness/hardening cleanup found by
>> : inspection. All checks are placed after the folio is resolved and before
>> : it is acted upon, on paths that already hold the relevant page-table lock,
>> : so no locking or refcount changes are involved.
>>
>> And you had to tweak the hmm-test driver to reproduce the bug(s).
>>
>> So when do we push this series out to -stable? As a hair-on-fire
>> hotfix, or as a leisurely next-merge-window thing?
>
>Thanks, Andrew :) Yeah, I'd say next merge window should be fine :)
>
>The crash is real once the mapping exists, but I had to tweak test_hmm
>to create that PMD-mapped device-coherent folio, and I couldn't find
>any in-tree production driver doing that today.
>
>So no need to rush this one, I guess.
BTW, noticed that the ZONE_DEVICE split handling only covers
device-private folios, so device-coherent folios aren't supported ...
The call chains are:
split_folio()
-> __folio_split()
-> folio_check_splittable()
-> __folio_freeze_and_split_unmapped()
migrate_vma_pages()
-> __migrate_device_pages()
-> migrate_vma_split_unmapped_folio()
-> folio_split_unmapped()
-> __folio_freeze_and_split_unmapped()
And I added the device-coherent check to folio_check_splittable() and
folio_split_unmapped(). See below. They can go away once device-coherent
folio splitting is supported :)
If folks think it's worth having, I can send it as a follow-up :)
---8<---
Subject: [PATCH] mm/huge_memory: don't split device-coherent folios
From: Lance Yang <lance.yang@linux.dev>
The ZONE_DEVICE split handling only covers device-private folios.
Device-coherent folios are not supported.
The call chains are:
split_folio()
-> __folio_split()
-> folio_check_splittable()
-> __folio_freeze_and_split_unmapped()
migrate_vma_pages()
-> __migrate_device_pages()
-> migrate_vma_split_unmapped_folio()
-> folio_split_unmapped()
-> __folio_freeze_and_split_unmapped()
Reject device-coherent folios in folio_check_splittable() and
folio_split_unmapped().
Fixes: a30b48bf1b24 ("mm/migrate_device: implement THP migration of zone device pages")
Signed-off-by: Lance Yang <lance.yang@linux.dev>
---
mm/huge_memory.c | 14 +++++++++++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 54494c3fa983..a5dd38e9a8de 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -3937,6 +3937,10 @@ int folio_check_splittable(struct folio *folio, unsigned int new_order,
if (!folio->mapping && !folio_test_anon(folio))
return -EBUSY;
+ /* TODO: Support splitting device-coherent folios. */
+ if (folio_is_device_coherent(folio))
+ return -EOPNOTSUPP;
+
/* order-1 is not supported for anonymous THP. */
if (folio_test_anon(folio) && new_order == 1)
return -EINVAL;
@@ -4354,15 +4358,16 @@ static int __folio_split(struct folio *folio, unsigned int new_order,
*
* anon_vma_lock is not required to be held, mmap_read_lock() or
* mmap_write_lock() should be held. @folio is expected to be locked by the
- * caller. device-private and non device-private folios are supported along
+ * caller. device-private and non-ZONE_DEVICE folios are supported along
* with folios that are in the swapcache. @folio should also be unmapped and
* isolated from LRU (if applicable)
*
* Upon return, the folio is not remapped, split folios are not added to LRU,
* free_folio_and_swap_cache() is not called, and new folios remain locked.
*
- * Return: 0 on success, -EAGAIN if the folio cannot be split (e.g., due to
- * insufficient reference count or extra pins).
+ * Return: 0 on success, -EOPNOTSUPP for device-coherent folios, or -EAGAIN if
+ * the folio cannot be split (e.g., due to insufficient reference
+ * count or extra pins).
*/
int folio_split_unmapped(struct folio *folio, unsigned int new_order)
{
@@ -4373,6 +4378,9 @@ int folio_split_unmapped(struct folio *folio, unsigned int new_order)
VM_WARN_ON_ONCE_FOLIO(!folio_test_large(folio), folio);
VM_WARN_ON_ONCE_FOLIO(!folio_test_anon(folio), folio);
+ if (folio_is_device_coherent(folio))
+ return -EOPNOTSUPP;
+
if (folio_expected_ref_count(folio) != folio_ref_count(folio) - 1)
return -EAGAIN;
--
Cheers, Lance
prev parent reply other threads:[~2026-08-30 7:47 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-17 22:08 Gregory Price
2026-08-17 22:08 ` [PATCH v2 1/3] mm/huge_memory: skip zone device folios in madvise_free_huge_pmd() Gregory Price
2026-08-17 22:08 ` [PATCH v2 2/3] mm/madvise: skip zone device folios in cold/pageout PMD range Gregory Price
2026-08-18 8:27 ` Balbir Singh
2026-08-17 22:08 ` [PATCH v2 3/3] mm/mempolicy: skip zone device folios when queueing folios Gregory Price
2026-08-17 23:34 ` Balbir Singh
2026-08-18 12:51 ` Gregory Price
2026-08-18 7:20 ` Lorenzo Stoakes (ARM)
2026-08-18 17:19 ` David Hildenbrand (Arm)
2026-08-18 4:31 ` [PATCH v2 0/3] mm: reject zone device folios in more folio walkers Lance Yang
2026-08-30 0:18 ` Andrew Morton
2026-08-30 5:18 ` Lance Yang
2026-08-30 7:47 ` Lance Yang [this message]
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=20260830074751.25370-1-lance.yang@linux.dev \
--to=lance.yang@linux.dev \
--cc=akpm@linux-foundation.org \
--cc=apopple@nvidia.com \
--cc=balbirs@nvidia.com \
--cc=baohua@kernel.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=byungchul@sk.com \
--cc=david@kernel.org \
--cc=dev.jain@arm.com \
--cc=gourry@gourry.net \
--cc=jannh@google.com \
--cc=joshua.hahnjy@gmail.com \
--cc=kernel-team@meta.com \
--cc=liam@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=matthew.brost@intel.com \
--cc=nico.pache@linux.dev \
--cc=rakie.kim@sk.com \
--cc=ryan.roberts@arm.com \
--cc=usama.arif@linux.dev \
--cc=vbabka@kernel.org \
--cc=ying.huang@linux.alibaba.com \
--cc=ziy@nvidia.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®