为什么不能在64位内核的32位Linux进程中映射（MAP_FIXED）最高虚拟页面？

为什么不能在64位内核的32位Linux进程中映射（MAP_FIXED）最高虚拟页面？

mmap函数最终调用do_mmap或do_brk_flags，它们执行满足内存分配请求的实际工作。这些函数依次调用get_unmapped_area。正是在该函数中进行检查，以确保不能分配超出TASK_SIZE定义的用户地址空间限制的内存。我引用代码：

 * There are a few constraints that determine this: * * On Intel CPUs, if a SYSCALL instruction is at the highest canonical * address, then that syscall will enter the kernel with a * non-canonical return address, and SYSRET will explode dangerously. * We avoid this particular problem by preventing anything executable * from being mapped at the maximum canonical address. * * On AMD CPUs in the Ryzen family, there's a nasty bug in which the * CPUs malfunction if they execute pre from the highest canonical page. * They'll speculate right off the end of the canonical space, and * bad things happen.  This is worked around in the same way as the * Intel problem.#define TASK_SIZE_MAX   ((1UL << __VIRTUAL_MASK_SHIFT) - PAGE_SIZE)#define IA32_PAGE_OFFSET    ((current->personality & ADDR_LIMIT_3GB) ?          0xc0000000 : 0xFFFFe000)#define TASK_SIZE       (test_thread_flag(TIF_ADDR32) ? IA32_PAGE_OFFSET : TASK_SIZE_MAX)

在具有48位虚拟地址空间的处理器上，

__VIRTUAL_MASK_SHIFT

值为47。

请注意，

TASK_SIZE

根据当前进程是32位32位，64位32位还是64位64位来指定。对于32位进程，将保留两个页面。一个用于vsyscall页面，另一个用作保护页面。本质上，无法取消映射vsyscall页面，因此用户地址空间的最高地址实际上是0xFFFFe000。对于64位进程，保留一个保护页。这些页面仅在64位Intel和AMD处理器上保留，因为仅在这些处理器

SYSCALL

上使用了该机制。

这是在中执行的检查

get_unmapped_area

：

if (addr > TASK_SIZE - len)     return -ENOMEM;