lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 21 Jun 2021 23:19:10 -0400 From: Peilin Ye <yepeilin.cs@...il.com> To: x86@...nel.org, Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>, Jonathan Corbet <corbet@....net> Cc: "H. Peter Anvin" <hpa@...or.com>, Joerg Roedel <jroedel@...e.de>, Cong Wang <xiyou.wangcong@...il.com>, Zefang Han <hanzefang@...il.com>, Wei Lin Chang <r09922117@...e.ntu.edu.tw>, linux-kernel@...r.kernel.org, linux-doc@...r.kernel.org, Peilin Ye <yepeilin.cs@...il.com> Subject: [PATCH] docs: x86: Remove obsolete information about x86_64 vmalloc() faulting x86_64 vmalloc() mappings are no longer "lazily synchronized" among page tables via page fault handling since commit 7f0a002b5a21 ("x86/mm: remove vmalloc faulting"). Subsequently, commit 6eb82f994026 ("x86/mm: Pre-allocate P4D/PUD pages for vmalloc area") rendered it unnecessary to synchronize, whether lazily or not, x86_64 vmalloc() mappings at runtime, since the corresponding P4D or PUD pages are now preallocated during system initialization by preallocate_vmalloc_pages(). Drop the "lazily synchronized" description for less confusion. It is worth noting, however, that there is still a slight complication for x86_32; see commit 4819e15f740e ("x86/mm/32: Bring back vmalloc faulting on x86_32") for details. Signed-off-by: Peilin Ye <yepeilin.cs@...il.com> --- Hi all, I was trying to understand vmalloc() when I saw this "lazily synchronized" statement, which confused me for a while. Please correct me if my understanding is wrong or out of date. Thank you, Peilin Ye Documentation/x86/x86_64/mm.rst | 4 ---- 1 file changed, 4 deletions(-) diff --git a/Documentation/x86/x86_64/mm.rst b/Documentation/x86/x86_64/mm.rst index ede1875719fb..9798676bb0bf 100644 --- a/Documentation/x86/x86_64/mm.rst +++ b/Documentation/x86/x86_64/mm.rst @@ -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 -- 2.25.1
Powered by blists - more mailing lists