64位Linux上的32位进程的地址空间
在这个答案中，作者指出： 使用 64 位 x86_64 内核，32 位进程可以使用整个 4GB 地址空间，除了由内核管理的 4GB 地址空间末尾的几个页面 (8KB)。
这个内核管理内存的用途是什么？难道它不应该在内核空间中，以防止用户意外损坏吗？
In this answer author states:With the 64-bit x86_64 kernel, a 32-bit process can use the entire 4GB address space, except for a couple pages (8KB) at the end of the 4GB address space which are managed by the kernel.
What is the purpose of this kernel-managed memory? Shouldn’t it be in the kernel space, to prevent accidental corruption by the user?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
引用内核源代码：“内核指针具有冗余信息，因此我们可以使用一种方案，可以返回错误代码或具有相同返回值的 [...] 指针。
” -1..-4095（在 32 位模式下映射到 0xfffff000–0xffffffff）保留用于内核级 errno 值。 0xffffe000–0xffffefff 中的另外 4KB 可供 vsyscall vdso magic page 使用，但由于 vdso page 自许多卫星以来都是可重定位的，因此该区域仍然可能无人居住，也就是说，
[stack]/proc/*/maps中的条目始终以 0xffffdfff 结尾，无论 [vdso] 是否映射到0xffffe000 或其他地方。Citing the kernel source: “Kernel pointers have redundant information, so we can use a scheme where we can return either an error code or a [...] pointer with the same return value.”
The values -1..-4095 (mapping to 0xfffff000–0xffffffff in 32-bit mode) are reserved for kernel-level errno values. The other 4KB from 0xffffe000–0xffffefff are held free for the vsyscall vdso magic page, but since the vdso page is relocatable since many moons, this area remains potentially unpopulated, that is to say, the
[stack]entry in/proc/*/mapsends at 0xffffdfff always regardless of whether [vdso] is mapped at 0xffffe000 or elsewhere.某些内核内存可以位于应用程序用户空间地址空间内，并且类似于 mmap-ed 为
PROT_NONE。然后将使用一些地址空间，但程序无法访问该地址空间（因此不可能出现损坏）。Some kernel memory can be inside the application user-space address space, and be sort-of mmap-ed with
PROT_NONE. Some address space would then be used, but without being accessible by the program (so no corruption is possible).