Re: [RFC PATCH 0/2] mm/memory_hotplug: bound offline retry loops with a configurable limit

["David Hildenbrand (Arm)" <david@kernel.org>]

On 7/22/26 09:48, Aboorva Devarajan wrote:
> Memory offlining can loop forever when a memory block holds a page that
> can never be migrated or freed.  This series adds an opt-in retry limit
> that lets offline_pages() bail out with -EBUSY instead of retrying
> forever.  The default (0) preserves today's behaviour exactly.
> 
> Patch 1 is the fix; patch 2 is an in-tree selftest that reproduces the
> hang from an unsignalable kworker and verifies the limit recovers it.
> 
> 1. The problem
> ==============
> 
> offline_pages() repeats two nested steps until the whole range is
> isolated:
> 
>   1. Inner loop: find and migrate movable pages out of the range
>      (scan_movable_pages() + do_migrate_range()).
>   2. Outer loop: re-check isolation (test_pages_isolated()); if not
>      fully isolated, go back to step 1.
> 
> Neither loop has a termination condition.  When a page can never be
> migrated, scan_movable_pages() keeps returning the same pfn,
> do_migrate_range() keeps failing on it, and control never even reaches
> the outer isolation re-check - the inner loop spins forever.  The admin
> guide acknowledges this:
> 
>   "Further, memory offlining might retry for a long time (or even
>    forever), until aborted by the user."
> 
> The single escape in the loop is signal_pending(current):
> 
>     offline_pages(pfn, end_pfn):
>         do {                                    /* outer: isolation */
>             do {                                /* inner: migration  */
>                 if (signal_pending(current))    /* <-- ONLY escape   */
>                         goto failed_removal;
>                 pfn = scan_movable_pages(pfn, end_pfn);
>                 do_migrate_range(pfn, end_pfn); /* may never succeed */
>             } while (pfn < end_pfn);
>         } while (test_pages_isolated(...));
> 
> 
> 2. Why the kernel itself should be able to bail
> ===============================================
> 
> We keep hitting this during memory hot-remove operations: a single
> stuck page can block the whole operation.  This was also reported in
> [4] earlier; one example, where offlining kept failing to migrate a
> busy block-device page-cache page (aops:def_blk_aops) in a normal zone:
> 
>   [10880.889199] page dumped because: migration failure
>   [10880.889232] migrating pfn 2a87b failed ret:1
>   [10880.889235] page: refcount:3 mapcount:0 mapping:00000000718ec5a6 index:0x857 pfn:0x2a87b
>   [10880.889241] aops:def_blk_aops ino:800003 dentry name(?):""
>   [10880.889245] flags: 0x33ffffe00004104(referenced|active|private|node=3|zone=0|lastcpupid=0x1fffff)
>   ...
>   [10880.889291] migrating pfn 2a87b failed ret:1

Hi,

the text reads AI generated. If you did use AI, please disclose it properly.

Quick feedback:

1) Using passes is not really what we want in many cases (e.g., ZONE_MOVABLE
where we might need a couple of seconds/minutes to complete offlining with a lot
of concurrent activity). An actual timeout is also problematic (see below).

2) Having a toggle for all offline_pages() users is questionable. In particular,
user-triggered offlining or offlinig triggered on ZONE_MOVABLE etc should not
obey such timeouts.

I proposed a more restricted approach only for offline_and_remove_memory()
previously [1]

[1] https://lore.kernel.org/all/20230627112220.229240-1-david@redhat.com/

Michal back then commented "I really hate having timeouts back. They just proven
to be hard to get right and it is essentially a policy implemented in the
kernel. They simply do not belong to the kernel space IMHO."

And I agree.

I assume you run into such issues with DIMMs in VMs? virtio-mem handles that
much nicer nowadays, by essentially doing the hard part that should fail easily
through alloc_contig_range().

offline_pages() is just designed to retry forever.

-- 
Cheers,

David