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

[Zi Yan <ziy@nvidia.com>]

On 21 Aug 2025, at 18:07, David Hildenbrand wrote:

> 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(-)

Acked-by: Zi Yan <ziy@nvidia.com>

>
> 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.
>



--
Best Regards,
Yan, Zi