Re: [BUG] mm/memory_hotplug: panic due to race between compaction and memory hot-unplug

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

On 11/4/26 06:18, Ketan Kishore wrote:
> 
> 
> On 9/10/2026 1:10 PM, David Hildenbrand (Arm) wrote:
>> On 9/10/26 05:16, Wei Yang wrote:
>>>
>>> Does it mean, the combination of pfn_to_online_page() / PageBuddy(page) is not
>>> safe, when there is hot-remove, even for other users. Not only compaction.
>>
>> There is an inherent race between any
>>
>> pfn_to_online_page() user that then takes a look at the memmap (PageBuddy,
>> whatever).
>>
>> Usually, that's not really relevant, because for things to go terrible wrong
>> (instead of only being slightly suboptimal :) )
>>
>> You have to run both, memory offlining *and* memory removal.
>>
> 
> Hello
> 
> We faced similar issue internally on one of our target's guest VM run,
> where kcompactd de-referenced a vmemmap pointer for a PFN after the hot-unplug
> path had already freed that vmemmap,with no lock preventing the two from running
> simultaneously.
> Call trace:
>   suitable_migration_target+0x0/0x8c (P)
>   migrate_pages_batch+0x1b4/0xc74
>   migrate_pages+0x150/0x654
>   compact_zone+0x5bc/0xb30
>   compact_node+0xa0/0x18c
>   kcompactd+0x228/0x4d0
> 
> Would it be okay to introduce something like "try_get_online_mems" as shown
> below to try a readlock in compaction path for hot-unplug to wait
> for kcompactd to complete before freeing the vmemmap?


Likely not what we want :)

Gregory started working on some fixes:

https://lore.kernel.org/r/20261027042204.3741307-1-gourry@gourry.net

They need more discussions. They are a little bit low priority as we are
fighting bigger fires ...


-- 
Cheers,

David