Linux 从保留堆栈空间分配mmap区域？

在我们的产品中，我们使用一个malloc实现，它完全依赖于mmap进行内存分配。我们也合理使用分配。我们刚刚遇到了一个问题，mmap将分配应该保留给堆栈空间的区域，因此当一个较大的alloca溢出到malloc'd区域时，会发生非常糟糕的事情

进程分配的限制是VM地址空间，而不是物理内存。我们观察了进程运行时的/proc/*/maps文件，并观察了malloc占用所有可用地址空间的情况。它最终求助于在堆栈rlimit集合范围内分配地址，最终一个大的alloca会延伸到其中

我们试图通过在启动时分配整个堆栈限制来解决这一问题，但事实证明，在2.6生产机器上运行时，在尝试访问我的2.4 dev box上的allocad内存时，跨平台的情况并不稳定

---

有没有办法实际保留地址空间？还可以做什么？

旧版本的heartbeat通过调用一个递归函数提交堆栈空间，该函数一次将1Kb内存设置为0xff。Heartbeat这样做是为了能够锁定它可能需要的所有内存。

这显然是最近记录的一个用于权限提升攻击的安全漏洞。据称较新的内核版本将被修补

---

对malloc使用mmap真是个坏主意。滥用alloca更糟糕。。。我第一次听说有人耗尽了虚拟内存空间。或者我们这里说的是32位？至少有两个广泛使用的malloc实现phkmalloc和jemalloc使用匿名mmap。我们使用的jemalloc是stdlib最新版本的malloc库。一定有人认为这是个好主意。是的，32位使用PME和半n半内核用户空间分割。此外，我们正在将内核中大约1千兆的内存映射到用户空间，因此我们的可用地址范围仅为大门外大约1千兆。@Dummy00001:我已经读到OpenBSD malloc mmaps everything>=pagesize。glibc和uClibc上使用的dlmalloc有一个MMAP_阈值，我认为通常在128Kb左右。@ninjal:OpenBSD:是的，他们特别在调优内核后激活了它，以支持以可接受的速度创建新映射。否则，进程的映射越多，上下文切换所需的时间就越多。即使是OpenBSD也无法避免这一点。大内存块的mmaping有着不同的含义：与heap不同，可以使用munmap将内存返回操作系统。您也可以通过brk将通过sbrk分配的堆内存返回操作系统。理想情况下，我可以以某种方式保留地址，而不必强制它们由内存支持，但就目前而言，我认为这是唯一可行的办法。