Re: [PATCH v2 2/2] mm/memory_hotplug: fix hwpoisoned large folio handling in do_migrate_range

[David Hildenbrand <david@redhat.com>]

On 21.08.25 07:02, Andrew Morton wrote:
> On Tue, 22 Jul 2025 17:30:06 +0200 David Hildenbrand <david@redhat.com> wrote:
> 
>> On 20.07.25 04:23, Andrew Morton wrote:
>>>
>>> I continue to retain the original patch in mm-hotfixes as part of
>>> akpm's lame bug-tracking system.  3 weeks in -next.
>>>
>>> And I just added a cc:stable to it because December 2018.
>>>
>>> I don't expect many real-world users will be putting fake delays in
>>> memory_failure(), but it's there.
>>>
>>> So what do we do here?  Add a TODO, merge it under the
>>> better-than-it-was-before theory and move on?
>>
>> I would feel better if we could just not fail memory offlining. Memory
>> offlining is documented to loop forever if something bad happens, and
>> user space can cancel it.
>>
> 
> Pathetic monthly prod to keep this on people's radar.
> 

Let's do something minimal for now:

 From 403b2a375a10c17fd6e2aeffbe0fdaf623faa621 Mon Sep 17 00:00:00 2001
From: Jinjiang Tu <tujinjiang@huawei.com>
Date: Fri, 27 Jun 2025 20:57:47 +0800
Subject: [PATCH] mm/memory_hotplug: fix hwpoisoned large folio handling in
  do_migrate_range

In do_migrate_range(), the hwpoisoned folio may be large folio, which
can't be handled by unmap_poisoned_folio().

I can reproduce this issue in qemu after adding delay in memory_failure()

BUG: kernel NULL pointer dereference, address: 0000000000000000
Workqueue: kacpi_hotplug acpi_hotplug_work_fn
RIP: 0010:try_to_unmap_one+0x16a/0xfc0
  <TASK>
  rmap_walk_anon+0xda/0x1f0
  try_to_unmap+0x78/0x80
  ? __pfx_try_to_unmap_one+0x10/0x10
  ? __pfx_folio_not_mapped+0x10/0x10
  ? __pfx_folio_lock_anon_vma_read+0x10/0x10
  unmap_poisoned_folio+0x60/0x140
  do_migrate_range+0x4d1/0x600
  ? slab_memory_callback+0x6a/0x190
  ? notifier_call_chain+0x56/0xb0
  offline_pages+0x3e6/0x460
  memory_subsys_offline+0x130/0x1f0
  device_offline+0xba/0x110
  acpi_bus_offline+0xb7/0x130
  acpi_scan_hot_remove+0x77/0x290
  acpi_device_hotplug+0x1e0/0x240
  acpi_hotplug_work_fn+0x1a/0x30
  process_one_work+0x186/0x340

Besides, do_migrate_range() may be called between memory_failure set
hwpoison flag and isolate the folio from lru, so remove WARN_ON(). In other
places, unmap_poisoned_folio() is called when the folio is isolated, obey
it in do_migrate_range() too.

Fixes: b15c87263a69 ("hwpoison, memory_hotplug: allow hwpoisoned pages to be offlined")
Signed-off-by: Jinjiang Tu <tujinjiang@huawei.com>
[ David: don't abort offlining, fixed typo, added comment ]
Signed-off-by: David Hildenbrand <david@redhat.com>
---
  mm/memory_hotplug.c | 10 ++++++++--
  1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index 1f15af712bc34..74318c7877156 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -1815,8 +1815,14 @@ static void do_migrate_range(unsigned long start_pfn, unsigned long end_pfn)
  			pfn = folio_pfn(folio) + folio_nr_pages(folio) - 1;
  
  		if (folio_contain_hwpoisoned_page(folio)) {
-			if (WARN_ON(folio_test_lru(folio)))
-				folio_isolate_lru(folio);
+			/*
+			 * unmap_poisoned_folio() cannot handle large folios
+			 * in all cases yet.
+			 */
+			if (folio_test_large(folio) && !folio_test_hugetlb(folio))
+				goto put_folio;
+			if (folio_test_lru(folio) && !folio_isolate_lru(folio))
+				goto put_folio;
  			if (folio_mapped(folio)) {
  				folio_lock(folio);
  				unmap_poisoned_folio(folio, pfn, false);
-- 
2.50.1


Man oh man, is hwpoison handling a mess.

-- 
Cheers

David / dhildenb