Re: [PATCH] x86/mm: Split a 1G direct mapping that hot-remove only partly covers

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

On 10/19/26 06:16, Cong Wang wrote:
> From: Cong Wang <cwang@multikernel.io>
> 
> Hot-remove works on memory blocks, 128M and up, while the kernel maps
> boot memory with 1G pages where it can. Removing a block that sits in
> such a 1G page covers only part of it, and remove_pud_table() then
> walks the memory that 1G page maps as if it were a PMD table. The
> removal succeeds, but it corrupts the first page of the 1G region, may
> free that page while still in use, and leaves the removed memory
> mapped.
> 
> Map the 1G leaf through 2M leaves first, under pgd_lock as
> set_memory_*() may change it for the rest of the 1G meanwhile.
> 
> Reproduced in a 3G QEMU guest booted with movablecore=1280M. We used a
> test module fills the first page of a 1G-mapped region with a known
> pattern, then calls offline_and_remove_memory() on one 128M block in
> that region. Before this patch, part of the pattern is zeroed and the
> 1G page stays. After this patch, the pattern is intact, the block is
> unmapped, the rest stays mapped through 2M pages, and adding the block
> back works.

Which in-tree mechanism can trigger this?

I would imagine only DIMM hotremove on bare metal. But let's be real, that is
never going to be < 1 GiB.

All other mechanisms (including DIMMs in virtual environments) get removed in
the same granularity they were added.

-- 
Cheers,

David