Conversation
Harry (Hyeonggon) Yoo
hyeyoo
Recently, I was debugging some intermittent boot failures and discovered that, on x86, forgetting to synchronize kernel page tables when installing new PGD entries can lead to kernel crashes.
Most of the time, PGD entries are populated during the boot process, and new tasks inherit page tables derived from the swapper process, so everything works fine.
However, if you're adding memory at runtime via memory hotplugging and populating new PGD entries for the vmemmap (i.e., the struct page array) and the direct mapping area, you need to iterate over all page tables in the system and update them accordingly to make it visible to all tasks.
Failing to handle this properly can lead to a situation where you think the page tables are set up correctly, but in reality, only init_mm.pgd (page table of the swapper process) was updated, not the page table of current task. This leads to kernel crashes since the PGD entry is not set up properly.
x86 code has mechanisms to handle this kind of synchronization, but it’s easy to be overlooked and introduce kernel crashes as the code evolves. Here’s my patch series that addresses the issue and aims to make it more robust: https://lore.kernel.org/linux-mm/20250709131657.5660-1-harry.yoo@oracle.com/
Most of the time, PGD entries are populated during the boot process, and new tasks inherit page tables derived from the swapper process, so everything works fine.
However, if you're adding memory at runtime via memory hotplugging and populating new PGD entries for the vmemmap (i.e., the struct page array) and the direct mapping area, you need to iterate over all page tables in the system and update them accordingly to make it visible to all tasks.
Failing to handle this properly can lead to a situation where you think the page tables are set up correctly, but in reality, only init_mm.pgd (page table of the swapper process) was updated, not the page table of current task. This leads to kernel crashes since the PGD entry is not set up properly.
x86 code has mechanisms to handle this kind of synchronization, but it’s easy to be overlooked and introduce kernel crashes as the code evolves. Here’s my patch series that addresses the issue and aims to make it more robust: https://lore.kernel.org/linux-mm/20250709131657.5660-1-harry.yoo@oracle.com/
0
1
7