在哪个网站可以搜画画做品百度客服在线客服入口

再来是千年的千年

不变是眷恋的眷恋

飞越宇宙无极限

我们永不说再见

——超兽武装

 完整代码见：SnowLegend-star/6.s081 at lazy (github.com)

Eliminate allocation from sbrk() (easy)

顾名思义，就是去掉sbrk()中调用growproc()的部分。1s完事儿。

Lazy allocation (moderate)

part02是为了修复part01挖的那个坑。代码实现在课上也是讲过的，这里粗略看一遍hints就行：

1、你可以在usertrap()中查看r_scause()的返回值是否为13或15来判断该错误是否为页面错误

老实说这个hint1真是说晚了，应该在page table那个lab就提出的。到这我才真正理解scause、spec、stval那几个寄存器真正的用法。可以看到scause值为12、13、15时都是页表相关的问题。

2、stval寄存器中保存了造成页面错误的虚拟地址，你可以通过r_stval()读取

3、参考***vm.c***中的uvmalloc()中的代码，那是一个sbrk()通过growproc()调用的函数。你将需要对kalloc()和mappages()进行调用

模仿uvmalloc()在usertrap中写一个分配页表的函数体就行。

4、使用PGROUNDDOWN(va)将出错的虚拟地址向下舍入到页面边界

这里有个坑，就是PGROUNDDOWN(va)这句的位置是有讲究的。但是part02检测不出来，part02只是测试了是否成功分配页表，而没有测试va的位置合法性。我去，原来没问题，是我冤枉了这句代码。

5、当前uvmunmap()会导致系统panic崩溃；请修改程序保证正常运行

6、如果内核崩溃，请在***kernel/kernel.asm***中查看sepc

7、使用pgtbl lab的vmprint函数打印页表的内容

这个hint放在part03比较好，由于part02用不到vmprint()，搞得我咋part03都忘记这个hint了。

8、如果您看到错误“incomplete type proc”，请include“spinlock.h”然后是“proc.h”

这个hint也应该放在part03。

growproc()修改如下

int
growproc(int n)
{uint sz;struct proc *p = myproc();sz = p->sz;// if(n > 0){//   if((sz = uvmalloc(p->pagetable, sz, sz + n)) == 0) {//     return -1;//   }// } else if(n < 0){//   sz = uvmdealloc(p->pagetable, sz, sz + n);// }p->sz = sz + n;if(n > 0){if((sz = uvmalloc(p->pagetable, sz, sz + n)) == 0) {return -1;}} else if(n < 0){sz = uvmdealloc(p->pagetable, sz, sz + n);}return 0;
}

Lazytests and Usertests (moderate)

这个part03我觉得可以算是半步hard难度了，要修改的小地方太多了。而且这部分给的几个hints有点隐晦，让人有点摸不着头脑。还是从分析hints着手：

1、Handle negative sbrk() arguments.

这个部分我在part02就已想实现了，但是感觉在usertrap内部实现不了，就先搁置一旁。想不到part03又要实现。抱着试一试的心态我把growproc()内部的uvmdealloc()搬过来试了下，还真的是这么实现的。

2、Kill a process if it page-faults on a virtual memory address higher than any allocated with sbrk().

这句话还是比较容易理解的，问题是在哪里实现呢？我想了许久还是没什么头绪，遂依然在usertrap内部添加判断，也可行。

3、Handle the parent-to-child memory copy in fork() correctly.

这句就显得十分晦涩了，乍一看还以为是要求我们在fork()进行适当的修改。我去翻了下《CSAPP》，看到里面说使用“写时复制”后，父进程和子进程都应该被标记为只读。如果真是这样也太麻烦了，那part03绝对是hard难度。一阵挠头发现仍然没有思路后，就先跳过这句了。我想着既然有这个hint，那测试点应该会涉及到这句话的实现测试。先把大体框架完成进行测试再说。

4、Handle the case in which a process passes a valid address from sbrk() to a system call such as read or write, but the memory for that address has not yet been allocated.

这个hint的要求一目了然，不过我开始也是不知道从哪里着手。权且跳过。

5、Handle out-of-memory correctly: if kalloc() fails in the page fault handler, kill the current process.

连着被前面的hints折磨，终于是看到了个通俗易懂又易于实现的hint。我兴高采烈地掉进了一个小坑：

usertrap内部的我都是用p->killed=1来终止进程的，自以为这种写法相当的地道。但在修改vm.c的walk()时发现貌似不能用p->killed=1这个操作来终止进程，于是灵机一动想到终止进程不是可以用exit(-1)吗？后来我还测试了下能不能在usertrap中把p->killed=1和exit(-1)互换。

可恶的是lazytests貌似不能检查这两者的差异，搞得我还以为上述两种方法是等价的。为后面usertests的报错埋下伏笔。

6、Handle faults on the invalid page below the user stack.

这句话也有点语焉不详，后来才发现就是检查va是不是溢出到了guard page。和hint2差不多，一个是判断是否超出上界，一个则是防止va溢出到了下界。

OK，把hints过完了一遍可以开始测试了。第一个报错如下：

 

在前面搞多了注释“panic：xxx”的操作之后，我下意识地就是来一手掩耳盗铃，直接把上述panic给注释了，发现没有效果才开始认真思考到底是什么原因。

查看出错的freewalk()发现是uvmunmap()没有彻底删除叶子表项导致这个painc。这时候就得用vmprint()检查一番了，有一说一官方不提供vmprint()我不认可。输出结果如下：

可以发现确实是有个叶子页表项没完全删除，我自己分析uvmunmap()和walk()半天不见思路，又问了下GPT是什么情况。都没得到想要的原因。在发现pagetable只有这一个异常的叶子pte后，我决定直接在freewalk()内部把这个pte删去。果然可行。

解决这个小问题后，我突然对如何解决hint3来了思路。遂在uvmcopy()来了收掩耳盗铃，注释掉了两句panic。因为父进程用sbrk()申请了堆空间之后，如果不立即使用这部分新空间，“写时分配”机制会维持PTE_V=0的状态。这时候调用fork()来生成子进程，子进程在复制父进程的空间layout就会遇到这部分父进程申请的新空间。所以得忽略PTE_V=0的判别，仍然将新空间复制到子进程的空间中。

完成上述步骤就可以通过lazytests了，接下来开始攻关usertests。遇到的第一个问题就给我难住了：

为了探究到底是什么原因导致的报错，我把sbrkmuch()仔细看了几遍。发现这个函数内部倒是没报错，是内核出了问题。而且有些测试虽然OK了，也是有类似的usertrap报错：

在发现scause无一例外都是d之后，我尝试了把scause=13也加入usertrap的页表分配中，问题由此得以解决。

else if(r_scause()==15 || r_scause()==13)

接下来就是处理最麻烦的部分了，也就是hint4：处理这种情形：进程从sbrk()向系统调用（如read或write）传递有效地址，但尚未分配该地址的内存。

 我最初的想法是在scause==8的那部分也加入页表分配的内容，发现这样会导致重映射。

然后我又想可不可以直接在sys_write()和sys_read()添加页表分配。事实证明这种方法是可行的，但是如果测试的系统调用过多，岂不是要重写每个系统调用函数，治标不治本。由于午觉没睡好有点犯困了，就去网上找了下简便方法。

处理第4种情况，即系统调用（比如write）传入的虚拟地址对应的内存并没有被分配。

首先搞清楚函数执行流程，在调用write后系统trap到内核态，执行copyin来把用户程序va处的内容复制到内核空间，此时若va处并未分配内存，walkaddr会返回0导致系统调用失败。因此我们要做的就是在walkaddr中分配内存。

处理进程将有效地址从sbrk（）传递给系统调用（例如读取或写入），但尚未分配该地址的内存的情况

由于write是系统调用，在内核中访问用户地址空间出现异常不会进入usertrap()函数，内核访问用户地址空间首先要找到和虚拟地址对应的物理地址，walkaddr完成这个工作，当pte不存在或者pte无效，返回0 但是这种情况在lazy allocation中是允许的

所以针对这个问题需要在walkaddr()函数进行和usertrap中相同的操作，为访问地址分配内存并映射到页表

上面两段话可谓是醍醐灌顶，可以从根源上解决类似的问题。我们在walkaddr()内部进行和usertrap相似的操作，区别是在walkaddr()中我们操作的对象是传入的va，而非usertrap中的stval。

最后一个小问题是边界判断。

这里如果不加等号就会报下列错误。这个报错和问题代码看起来可谓是毫无关联，让我一番好找。

修改后的walkaddr()如下

uint64
walkaddr(pagetable_t pagetable, uint64 va)
{pte_t *pte;uint64 pa;if(va >= MAXVA)return 0;pte = walk(pagetable, va, 0);if(pte == 0 || (*pte & PTE_V)==0 ){struct proc *p=myproc();//由于write是系统调用，在内核中访问用户地址空间出现异常不会进入usertrap()函数uint64 mem;if(va >= p->sz)    //这里如果用low_addr > maxva就无法通过unmap测试return 0;if(va < p->trapframe->sp )  //即出错的地址位于guard pagereturn 0;mem=(uint64)kalloc();if(mem==0){return 0;}else{va = PGROUNDUP(va);       //加不加都行memset((void *)mem, 0, PGSIZE);if(mappages(p->pagetable, va, PGSIZE, mem, PTE_W|PTE_R|PTE_U)!=0){kfree((void*)mem);return 0;}}}if((*pte & PTE_U) == 0)return 0;pa = PTE2PA(*pte);return pa;}

修改后的usertrap()如下

  else if(r_scause()==15 || r_scause()==13){  //如果是出现缺页错误uint64 mem;// uint64 low_addr=PGROUNDDOWN(r_stval());//这里提早向下舍入low_addr是不是有问题啊？uint64 low_addr=r_stval();// printf("page fault %p\n", r_stval());if(low_addr >= p->sz)    //这里如果用low_addr > maxva就无法通过unmap测试// p->killed=1 ;exit(-1);if(low_addr < p->trapframe->sp )  //即出错的地址位于guard page// p->killed=1;exit(-1);mem=(uint64)kalloc();if(mem==0){// uvmdealloc(p->pagetable, low_addr, p->sz - low_addr);//用killed参数来杀死进程，而不是直接return  用kill的方式会导致  test copyinstr3: unlink(x) returned 0, not -1// p->killed=1;exit(-1);         //用exit(-1)也可以，一步到位}else{memset((void *)mem, 0, PGSIZE);low_addr=PGROUNDDOWN(low_addr);if(mappages(p->pagetable, low_addr, PGSIZE, mem, PTE_W|PTE_R|PTE_U)!=0){kfree((void*)mem);// uvmdealloc(p->pagetable, low_addr, p->sz - low_addr);// p->killed=1;   exit(-1);   }}}