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

[Cong Wang]

On Mon, Oct 19, 2026 at 3:26 AM David Hildenbrand (Arm)
<david@xxxxxxxxxx> wrote:
>
> On 10/19/26 06:16, Cong Wang wrote:
> > From: Cong Wang <cwang@xxxxxxxxxxxxxx>
> >
> > 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.

You're right.

The only in-tree path I can see is ACPI hot-remove of boot memory,
where the direct map was built over contiguous E820 RAM and a 1G page
can straddle DIMM boundaries that are not 1G aligned. I agree that is
unlikely on real firmware.

Where I actually hit it is removing 128M blocks of boot memory
(offline_and_remove_memory()) for the multikernel work, which is not
upstream. Happy to carry this patch downstream.

Thanks,
Cong