docs: x86: Remove obsolete information about x86_64 vmalloc() faulting

x86_64 vmalloc() mappings are no longer "synchronized" among page tables
via faulting since commit 6eb82f9940 ("x86/mm: Pre-allocate P4D/PUD
pages for vmalloc area"), since the corresponding P4D or PUD pages are
now preallocated at boot, by preallocate_vmalloc_pages().  Drop the
"lazily synchronized" description for less confusion.

While this file is x86_64-specific, it is worth noting that things are
different for x86_32, where vmalloc()-related changes to `init_mm.pgd` are
synchronized to all page tables in the system during runtime, via
arch_sync_kernel_mappings().  Unfortunately, this synchronization is
subject to race condition, which is further handled via faulting, see
vmalloc_fault().  See commit 4819e15f74 ("x86/mm/32: Bring back vmalloc
faulting on x86_32") for more details.

Reviewed-by: Muchun Song <songmuchun@bytedance.com>
Signed-off-by: Peilin Ye <peilin.ye@bytedance.com>
Reviewed-by: Joerg Roedel <jroedel@suse.de>
Link: https://lore.kernel.org/r/20210818220123.2623-1-yepeilin.cs@gmail.com
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
This commit is contained in:
Peilin Ye 2021-08-18 15:01:23 -07:00 committed by Jonathan Corbet
parent d44f571ff5
commit 251a7b3edc

View File

@ -140,10 +140,6 @@ The direct mapping covers all memory in the system up to the highest
memory address (this means in some cases it can also include PCI memory
holes).
vmalloc space is lazily synchronized into the different PML4/PML5 pages of
the processes using the page fault handler, with init_top_pgt as
reference.
We map EFI runtime services in the 'efi_pgd' PGD in a 64Gb large virtual
memory window (this size is arbitrary, it can be raised later if needed).
The mappings are not part of any other kernel PGD and are only available