ARM64下能否通过setrlimit强制mmap返回64GB范围内虚拟地址

你提到的setrlimit机制纯粹是资源配额管控工具，完全不会对虚拟地址的取值区间形成强制约束。

为什么setrlimit达不到地址范围约束的效果 #

RLIMIT_AS的作用逻辑非常简单直接：

• 只统计进程下所有已映射、预留的虚拟地址的总大小
• 当新的mmap、brk、栈扩展等操作会让总大小超过设定的软/硬上限时，直接返回ENOMEM失败
• 全程不会干预内核选择哪个具体的虚拟地址来满足分配请求——哪怕你把上限设得极低，内核依然可以选择高地址段的空闲块来满足分配，只要算上这次申请后总大小不超配额就行。

对你的场景来说，普通应用的虚拟内存占用通常也就几GB到几十GB，远低于47位地址空间能覆盖的128TB总大小，就算你把RLIMIT_AS设成128TB，这个限制永远不会被触发，内核完全可以自由分配47位以上的空闲地址给LuaJIT的mmap请求，靠setrlimit根本达不到你要的效果。

适配无源码程序的可行实现 #

既然你本来就打算用预加载动态库介入流程，完全不需要依赖setrlimit，通过以下几种方式就能强制让所有mmap请求返回47位及以下的地址：

• 最简便的实现方式：在预加载库的初始化阶段直接调整mmap的分配基地址
  • 调用prctl(PR_SET_MM, PR_SET_MM_MMAP_BASE_ADDR, 0x7f0000000000, 0, 0)，把mmap的分配起点直接设置到47位边界以下的位置
  • 内核收到这个调整后，所有后续的mmap分配都会从这个新的基地址开始扫描空闲页，完全不会跑到47位以上的地址段，从根源上解决地址越界的问题
  • 这个操作不需要特殊权限，进程在初始化阶段直接调用即可，没有任何额外开销
• 兼容性更强的实现方式：预占高地址段强制下沉mmap分配区
  • 在预加载的初始化阶段（程序main函数执行前），先通过读取/proc/self/maps识别出当前已经映射的内存段（动态链接器、主程序、已加载动态库、栈的位置）
  • 把47位边界（0x800000000000）以上的所有空闲地址段，搭配MAP_FIXED_NOREPLACE标志映射为PROT_NONE的不可访问属性
  • 这种预留只占用虚拟地址空间，不会消耗任何物理内存或交换空间，没有实际资源开销
  • 因为内核无法把已经映射的地址段分配给后续的mmap请求，原来位于高地址段的mmap分配区会被完全挡死，内核会自动把mmap的分配起点下移到47位以下的空闲地址段
• 精细化控制的实现方式：在预加载库中直接hook内存分配相关的系统调用
  • 拦截程序发起的mmap、mmap64请求，主动检查内核返回的地址是否超过47位边界
  • 如果地址超限，就主动unmap掉这块返回的地址，重新发起分配，直到拿到符合范围要求的结果为止

注意事项 #

• 不要在setrlimit的参数调整上浪费时间，它的设计初衷就不是用来限制地址取值范围的，怎么配置都起不到约束地址位置的作用
• 做高地址段预留的时候，一定要用MAP_FIXED_NOREPLACE标志，避免意外覆盖已经映射的栈、动态库、主程序的地址段
• 直接调整mmap基地址的方式要求内核版本不低于4.17，太老的内核不支持这个操作，可以退用高地址段预留的方案

内容的提问来源于stack exchange，提问作者DeanSinaean