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 22:32, Cong Wang wrote:
> On Mon, Oct 19, 2026 at 3:26 AM David Hildenbrand (Arm)
> <david@kernel.org> wrote:
>>
>> 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.
> 
> 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.

It should definitely not be tagged as a fix. Given that we don't expect in-tree
users (and also don't endorse ones that remove arbitrary boot memory they don't
actually own), I'm not sure if we want this at this point.

I'll leave it up to x86 folks.

(IMHO we should, however, definitely warn if we would run into this situation)

-- 
Cheers,

David