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/[email protected]/
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
