UNIX/Linux
的stack在大多數(shù)平臺(tái)是向下擴(kuò)展的(注意，我已經(jīng)告訴他事實(shí)了，我并沒有問…是如何擴(kuò)展的，這是可以背誦下來并朗讀出來的)，在一個(gè)執(zhí)行流調(diào)用了
一個(gè)函數(shù)A，而該函數(shù)A在stack上分配了一個(gè)大數(shù)組導(dǎo)致了stack擴(kuò)展(注意，這又是一段陳述，我還沒有給出問題)，然后A返回
了，UNIX/Linux理應(yīng)回收調(diào)A里面大數(shù)組分配stack空間-因?yàn)樗僖矝]有用了，但是它并沒有這么做(這里可能是一個(gè)陷阱，真的是UNIX
/Linux理應(yīng)這么做卻沒有做，還是說我只是在逗你玩…不確定，但陳述就是如此)。(注意，我的問題來了)，請(qǐng)問，UNIX/Linux為什么這么
做？！！！
凡是回答操作系統(tǒng)這么規(guī)定的之類的答案，一律零分！況且，你能證明我說的一定對(duì)嗎？萬一我是逗你玩呢？操作系統(tǒng)能規(guī)定一個(gè)錯(cuò)的東西嗎？或者我可以繼續(xù)問為
什么這么規(guī)定，直到像我初中的歷史老師被我問到朝我眼角猛打一拳那樣，如果我能找回點(diǎn)賤人所謂的快感，那么來打吧！問題就是這樣，不管這個(gè)問題是一個(gè)偽命
題還是你有自己的想法，能說5分鐘的，我覺得也夠可以了。該題目的答題要求如下：
時(shí)間限制：5分鐘。
作答方式：全口述，不能畫圖，不能打手勢(shì)…語言含糊不清的，表達(dá)能力不好的，算錯(cuò)誤。
答題建議：如果你對(duì)OS虛擬內(nèi)存管理以及Linux的VMA實(shí)現(xiàn)細(xì)節(jié)沒有相當(dāng)深入的理解，請(qǐng)不要猜測(cè)答案。請(qǐng)直接回答“不知道”，然后看完此文。
……………………………
5分鐘過去。我要公布一點(diǎn)我的想法了。
首先，這個(gè)問題在本身看來，有問題。因?yàn)殡m然Linux理應(yīng)這么做，但它：
第一，它不一定能做到；
第二，它根本沒有必要做。
那么論據(jù)是什么？憑什么這樣說？
積極論點(diǎn)
沒必要這樣做。執(zhí)行流還會(huì)調(diào)用別的函數(shù)或者再次調(diào)用A，頻繁回收棧損耗性能；
消極論點(diǎn)
很難或者不能做到。stack操作是處理器控制的，和OS內(nèi)核地址空間管理機(jī)制之間沒有同步機(jī)制，一個(gè)函數(shù)調(diào)用結(jié)束后，CPU自動(dòng)處理stack寄存器的收縮，彈出棧幀，然而它無法通知OS內(nèi)存管理系統(tǒng)去更新進(jìn)程地址空間的映射關(guān)系。
如何處理stack所在地址空間區(qū)域的爭(zhēng)議
stack
會(huì)一直擴(kuò)展到碰到異常的地址B，B可能是一個(gè)readonly的地址或者是一個(gè)保護(hù)空洞，在向下擴(kuò)展stack情況下，如果地址B偏上，會(huì)導(dǎo)致stack
空間變小，如果偏下，一旦函數(shù)局部變量幾乎占滿了stack底到B的空間，mmap雖然也能unmap掉這段區(qū)域然后remap，然而這會(huì)使數(shù)據(jù)混亂，造
成嚴(yán)重問題。
拍腦袋的結(jié)論
mmap或者brk期間，比較stack頂部與esp寄存器，若小于則回收（等于是正常的，大于是不可能的）。
Linux真實(shí)的做法
Linux
沒有判斷什么esp寄存器，Linux的原則很簡(jiǎn)單，只要一個(gè)地址處在一個(gè)vma范圍內(nèi)或者處在stack可擴(kuò)展的范圍內(nèi)，且擁有權(quán)限的，它就是可以訪
問，內(nèi)核是不管這個(gè)VMA是屬于stack還是heap或者別的什么，具體由應(yīng)用程序自己控制，也就是說，你完全可以寫一段代碼，把地址空間中所有可以寫
的區(qū)域全部清零，這完全有可能，緩沖區(qū)溢出可能是一種蓄意的破壞，然而程序員偶然的錯(cuò)誤也會(huì)造成破壞，雖然他們大多數(shù)都不知道錯(cuò)誤是如何發(fā)生的。我不想用
文字長(zhǎng)篇大論Linux是如何管理VMA的，你知道這個(gè)應(yīng)該是一個(gè)前提，你必須知道這個(gè)。我用一段代碼以及兩個(gè)圖示來展示Linux系統(tǒng)內(nèi)核是如何管理
stack附近的地址空間映射的，并且在第二張圖中給出，如果你非要蓄意破壞，會(huì)造成什么問題。也就是說，一旦發(fā)生莫名奇妙的錯(cuò)誤，你必須能從細(xì)節(jié)上理解
這個(gè)錯(cuò)誤是如何發(fā)生的。
演示代碼
#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <unistd.h>
#include <sys/mman.h>
#define LARGE 70000000
#define PAGESIZE 4096
// 該函數(shù)什么都不做，僅僅為了把stack向下擴(kuò)展
// 請(qǐng)注意用ulimit將stack大小限制去掉，這樣會(huì)更容易說明問題
void call()
{
int i;
char a[LARGE];
// 請(qǐng)相信，一定是在中間的賦值中觸發(fā)segfault，因?yàn)閮蛇叺脑匾刺幵趕tack/fixmap vma，
// 要么處在游離的，及其孤獨(dú)的，被fixmap給截?cái)嗔说膙ma中。因此下面的賦值不會(huì)引發(fā)段錯(cuò)誤：
// a[0] = 1;
// a[LARGE-1] = 1;
for (i = 0; i < LARGE; i ) {
a[i] = 1;
}
}
int main(int argc, char **argv)
{
int i;
char *p_map, *p_base, *p_base2;
printf(%d\\\\ninit state\\\\n, getpid());
// 獲取stack的大致地址，并且PAGESIZE對(duì)齊。
p_base = (char *)&i;
p_base2 = (char *)(((unsigned long)p_base) & ~4095);
// 獲取pagesize對(duì)齊的用來fixmap的地址，該地址起點(diǎn)在當(dāng)前stack的下面。
p_base2 = (char *)((unsigned long)p_base2 - (unsigned long)36*PAGESIZE);
getchar();
// 調(diào)用fixmap，顯然，如果你仔細(xì)在getchar期間分析了/proc/xx/maps文件并且
// 得到了上述的那些magic number，下面的mmap無論如何是會(huì)成功的！
p_map = (char *)mmap((void*)p_base2, PAGESIZE*3, PROT_READ | PROT_WRITE,
MAP_FIXED |MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
if (p_map == MAP_FAILED) {
printf(failed 1\\\\n);
} else {
printf(before unmap fixmap around stack\\\\n);
getchar();
// 成功了就釋放掉它，此時(shí)的地址空間恢復(fù)成mmap之前的狀況
munmap(p_map, PAGESIZE*3);
}
printf(after unmap fixmap around stack\\\\n);
getchar();
call();
printf(after extend stack[first]\\\\n);
getchar();
// 依然調(diào)用之前的那個(gè)一模一樣的mmap進(jìn)行fixmap，由于調(diào)用了call，stack
// 空間已經(jīng)擴(kuò)展到了這個(gè)fixmap的fixaddress，很遺憾，成功了，然而它將stack vma
// 一刀切成了兩段。不管怎樣，訪問還是可以進(jìn)行的。
p_map = (char *)mmap((void*)p_base2, PAGESIZE*3, PROT_READ | PROT_WRITE,
MAP_FIXED |MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
if (p_map == MAP_FAILED) {
printf(failed 2\\\\n);
}
printf(after second fixmap around stack at the same address\\\\n);
getchar();
// 這里更狠！部分unmap了上面那個(gè)fixmap vma，留下一個(gè)空洞。
munmap(p_map, PAGESIZE);
printf(after unmap fixmap around stack incompletely\\\\n);
getchar();
// 當(dāng)空洞被touch的時(shí)候，不會(huì)引發(fā)stack extend！而是直接segfault！爆炸！
call();
// 永遠(yuǎn)不會(huì)到達(dá)這里！
printf(after extend stack[second]\\\\n);
getchar();
return 0;
}
針對(duì)上述代碼的圖解
下面一幅圖展示一直到出事之前，該進(jìn)程的stack附近的地址空間映射區(qū)域是怎么演化的：
下面一幅圖展示出事的過程以及這個(gè)事故的原因：
測(cè)試方式
如
果你覺得圖是我自己畫出來的，那么肯定有一個(gè)疑問，我是基于什么畫出來的，事實(shí)上，我并不是通過看代碼畫出來的，我是通過不斷查看procfs的maps
文件實(shí)時(shí)了解該進(jìn)程地址空間的細(xì)節(jié)，將其轉(zhuǎn)換成了上面的圖示，為了讓我有機(jī)會(huì)到另一個(gè)終端去查maps文件，我在代碼中增加了getchar調(diào)用，每次查
看完maps文件，我會(huì)拍一下鍵盤的回車鍵。我的測(cè)試如下：
代碼編譯后的進(jìn)程輸出
root@abcd:~# ./a.out
7846
init state
before unmap fixmap around stack
after unmap fixmap around stack
after extend stack[first]
after second fixmap around stack at the same address
after unmap fixmap around stack incompletely
段錯(cuò)誤 (core dumped)
以下是查看每一步進(jìn)程maps文件的輸出：
root@abcd:~# cat /proc/`ps -e|grep a.out|awk \\\'{print $1}\\\’`/maps |tail -n 6|head -n 4
2b2c01483000-2b2c01487000 r–p 00157000 fe:00 387296 /lib/libc-2.11.2.so
2b2c01487000-2b2c01488000 rw-p 0015b000 fe:00 387296 /lib/libc-2.11.2.so
2b2c01488000-2b2c0148f000 rw-p 00000000 00:00 0
7fff6236a000-7fff6237f000 rw-p 00000000 00:00 0 [stack]
root@abcd:~# cat /proc/`ps -e|grep a.out|awk \\\'{print $1}\\\’`/maps |tail -n 6|head -n 4
2b2c01487000-2b2c01488000 rw-p 0015b000 fe:00 387296 /lib/libc-2.11.2.so
2b2c01488000-2b2c0148f000 rw-p 00000000 00:00 0
7fff62359000-7fff6235c000 rw-p 00000000 00:00 0
7fff6236a000-7fff6237f000 rw-p 00000000 00:00 0 [stack]
root@abcd:~# cat /proc/`ps -e|grep a.out|awk \\\'{print $1}\\\’`/maps |tail -n 6|head -n 4
2b2c01483000-2b2c01487000 r–p 00157000 fe:00 387296 /lib/libc-2.11.2.so
2b2c01487000-2b2c01488000 rw-p 0015b000 fe:00 387296 /lib/libc-2.11.2.so
2b2c01488000-2b2c0148f000 rw-p 00000000 00:00 0
7fff6236a000-7fff6237f000 rw-p 00000000 00:00 0 [stack]
root@abcd:~# cat /proc/`ps -e|grep a.out|awk \\\'{print $1}\\\’`/maps |tail -n 6|head -n 4
2b2c01483000-2b2c01487000 r–p 00157000 fe:00 387296 /lib/libc-2.11.2.so
2b2c01487000-2b2c01488000 rw-p 0015b000 fe:00 387296 /lib/libc-2.11.2.so
2b2c01488000-2b2c0148f000 rw-p 00000000 00:00 0
7fff5e0bb000-7fff6237f000 rw-p 00000000 00:00 0 [stack]
root@abcd:~# cat /proc/`ps -e|grep a.out|awk \\\'{print $1}\\\’`/maps |tail -n 6|head -n 4
2b2c01488000-2b2c0148f000 rw-p 00000000 00:00 0
7fff5e0bb000-7fff62359000 rw-p 00000000 00:00 0
7fff62359000-7fff6235c000 rw-p 00000000 00:00 0
7fff6235d000-7fff6237f000 rw-p 00000000 00:00 0 [stack]
root@abcd:~# cat /proc/`ps -e|grep a.out|awk \\\'{print $1}\\\’`/maps |tail -n 6|head -n 4
2b2c01488000-2b2c0148f000 rw-p 00000000 00:00 0
7fff5e0bb000-7fff62359000 rw-p 00000000 00:00 0
7fff6235a000-7fff6235c000 rw-p 00000000 00:00 0
7fff6235d000-7fff6237f000 rw-p 00000000 00:00 0 [stack]
我怕上面的文字信息太亂，格式在不同瀏覽器會(huì)有問題，我還特意截了一張圖：
有什么用
你
可以用這種方式徹底限制一個(gè)進(jìn)程的stack的大小，越界了不是報(bào)錯(cuò)，而是segfault。然后你可以signal捕獲這個(gè)segfault，在里面把
那個(gè)未完全unmap的fixmap vma以及那個(gè)可憐且孤獨(dú)的殘缺的stack
vma給徹底u(yù)nmap掉。不過這確實(shí)沒什么好玩的。有什么用呢？它的作用就是讓你更加深入理解Linux對(duì)虛擬地址空間的管理方式。
小Tips
本文不涉及線程棧，但是倒也不難，線程棧一般在heap區(qū)或者中間的大塊mmap區(qū)動(dòng)態(tài)分配，mmap的時(shí)候給它一個(gè)MAP_GROWSDOWN標(biāo)志就可以了。關(guān)于它的管理方式，沒啥差別。核心問題在于，缺頁異常處理程序是怎么識(shí)別到一個(gè)缺頁是一個(gè)vma內(nèi)部的缺頁(結(jié)果就是調(diào)頁)，還是vma外部的缺頁。在后一種情況下，缺頁處理邏輯還要進(jìn)一步識(shí)別是stack的缺頁(結(jié)果就是extend stack然后調(diào)頁)，還是非stack缺頁(結(jié)果就是segfault…)。
Linux的stack除非遇到本文所述的這種方式的擠兌收縮，它是永遠(yuǎn)擴(kuò)展的。如果你想閱讀Linux的內(nèi)核代碼，那么也需要理解下面的事實(shí)：
1.find_vma函數(shù)能找到vma只有一個(gè)限制，即輸入地址只要小于查找vma的end即可，并非很多人想象的那樣輸入地址必須處在查找vma的start和end之間；
2.find_vma函數(shù)之所以實(shí)現(xiàn)得如此incompletely，是因?yàn)闉榱撕?jiǎn)化缺頁中斷的處理，同時(shí)也是為了提供一種更加統(tǒng)一的方式同時(shí)處理upgrows和downgrows的vma。
后話
雖
然這個(gè)問題問得有點(diǎn)亂，但是如果能找上述回答連續(xù)扯5分鐘的，應(yīng)該是真行！不過我不知道怎樣的語言表達(dá)能力可以不用圖解和代碼把上面的每一個(gè)細(xì)節(jié)說清
楚…總之，我覺得我的這個(gè)題目是一個(gè)好題目。可以建議給看到此文的人，把它做面試題吧。凡是發(fā)現(xiàn)不了題目問題的以及說不出所以然的，一律不要！這真是
一道好測(cè)試題啊，它是如此之好，以至于我還想再出幾道比它更好的。
更多關(guān)于云服務(wù)器，域名注冊(cè)，虛擬主機(jī)的問題，請(qǐng)?jiān)L問三五互聯(lián)官網(wǎng)：m.shinetop.cn
