MIT 6.S081 Lab5 Copy-On-Write Fork
前言
最近绝大多数的空闲时间都拿来锤15-445了，很久没动6.S081。前几天回头看了一下一个月前锤完的Lazy Allocation，自己写的代码几乎都不认识了.......看来总结之类的东西最好还是趁着热乎的时候写啊。
不过15-445的内容实在太多了，我只是为了锤Lab粗略的看了看课件，课件里很多东西都没研究，相关的总结还是推迟到所有Lab锤完后重新整理一下再写吧。先把几天前刚做完的Copy-On-Write给写出来。最近会把前面草草写下的Lab Lazy Allocation的相关内容整改一下，补上具体的Lab。
Lab5 Copy-On-Write fork的链接：https://pdos.csail.mit.edu/6.828/2019/labs/cow.html
最近xv6-riscv-2019好像被改动过了，我git clone下来的时候发现usertest中多了不少的新测试，trap.c的代码也被改过了。
xv6进程的结构
想要处理好这个Lab，需要我们对xv6的进程结构有一个大致的了解。而了解xv6的进程结构，最好的办法是阅读kernel/exec.c的代码。xv6的进程结构大致如上图所示。我们下面对每个进程段进行简要分析：
ELF LOAD 段
ELF LOAD段是我自己给这个段起的名字,你们谷歌查是查不到的....我实在不知道到底该怎么称呼这个段.....
ELF LOAD段是在调用exec时，由ELF文件加载进来的段。我们可以查看一下_sh这个ELF文件的描述：
ms@ubuntu:~/public/MIT 6.S081/Lab5 cow/xv6-riscv-fall19$ readelf -a user/_sh
ELF 头：
Magic： 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
类别: ELF64
数据: 2 补码，小端序 (little endian)
版本: 1 (current)
OS/ABI: UNIX - System V
ABI 版本: 0
类型: EXEC (可执行文件)
系统架构: RISC-V
版本: 0x1
入口点地址： 0xa60
程序头起点： 64 (bytes into file)
Start of section headers: 39464 (bytes into file)
标志： 0x5, RVC, double-float ABI
本头的大小： 64 (字节)
程序头大小： 56 (字节)
Number of program headers: 1
节头大小： 64 (字节)
节头数量： 19
字符串表索引节头： 18
节头：
[号] 名称 类型 地址 偏移量
大小 全体大小 旗标 链接 信息 对齐
[ 0] NULL 0000000000000000 00000000
0000000000000000 0000000000000000 0 0 0
[ 1] .text PROGBITS 0000000000000000 00000078
000000000000127e 0000000000000000 WAX 0 0 2
[ 2] .rodata PROGBITS 0000000000001280 000012f8
0000000000000159 0000000000000000 A 0 0 8
[ 3] .sdata PROGBITS 00000000000013e0 00001458
000000000000000e 0000000000000000 WA 0 0 8
[ 4] .sbss NOBITS 00000000000013f0 00001466
0000000000000008 0000000000000000 WA 0 0 8
[ 5] .bss NOBITS 00000000000013f8 00001466
0000000000000078 0000000000000000 WA 0 0 8
[ 6] .comment PROGBITS 0000000000000000 00001466
0000000000000012 0000000000000001 MS 0 0 1
[ 7] .riscv.attributes LOPROC+0x3 0000000000000000 00001478
0000000000000035 0000000000000000 0 0 1
[ 8] .debug_aranges PROGBITS 0000000000000000 000014b0
00000000000000f0 0000000000000000 0 0 16
[ 9] .debug_info PROGBITS 0000000000000000 000015a0
00000000000021c2 0000000000000000 0 0 1
[10] .debug_abbrev PROGBITS 0000000000000000 00003762
00000000000006f1 0000000000000000 0 0 1
[11] .debug_line PROGBITS 0000000000000000 00003e53
0000000000002018 0000000000000000 0 0 1
[12] .debug_frame PROGBITS 0000000000000000 00005e70
0000000000000880 0000000000000000 0 0 8
[13] .debug_str PROGBITS 0000000000000000 000066f0
000000000000039f 0000000000000001 MS 0 0 1
[14] .debug_loc PROGBITS 0000000000000000 00006a8f
0000000000002386 0000000000000000 0 0 1
[15] .debug_ranges PROGBITS 0000000000000000 00008e15
0000000000000080 0000000000000000 0 0 1
[16] .symtab SYMTAB 0000000000000000 00008e98
00000000000008b8 0000000000000018 17 26 8
[17] .strtab STRTAB 0000000000000000 00009750
0000000000000218 0000000000000000 0 0 1
[18] .shstrtab STRTAB 0000000000000000 00009968
00000000000000bc 0000000000000000 0 0 1
........
可以看出，ELF LOAD段包含了程序的代码段、静态数据段、只读数据段、全局变量段、DEBUG信息等。exec函数一次申请一页，然后读取ELF文件的一页，读取完成后，将虚实映射关系添加到该进程的页表中。当ELF文件读取完后，ELF LOAD段也被加载到了进程的最低虚地址上，相应的虚实映射关系也被添加到了页表中。
stack guard page 段
xv6作为一个教学系统，它有很多设计不合理的地方。最明显的一点莫过于栈和堆的设置。很多OS书上告诉我们，进程的stack和heap是共用一块空间的，但它们的增长方向相反。当其中一个逾越到另一个的空间时，即认为空间已满，触发overflow。但xv6的栈却放在了低地址段，栈向下增长，堆放在了高地址段，向上增长......
吐槽完xv6，回过头来讨论这个段。因为stack是向低地址增长的，很可能会踩到ELF LOAD段不应该访问的区域，因此可以考虑在stack的PAGE和ELF LOAD的PAGE间设立GUARD PAGE，当用户访问这一段的时候触发page fault，告知用户栈溢出。
在kernel/exec.c中相关代码如下：
// kernel/exec.c
// Allocate two pages at the next page boundary. // Use the second as the user stack. sz = PGROUNDUP(sz); if((sz = uvmalloc(pagetable, sz, sz + 2*PGSIZE)) == 0) goto bad; uvmclear(pagetable, sz-2*PGSIZE); sp = sz; stackbase = sp - PGSIZE;
// kernel/vm.c
// mark a PTE invalid for user access. // used by exec for the user stack guard page. void uvmclear(pagetable_t pagetable, uint64 va) { pte_t *pte; pte = walk(pagetable, va, 0); if(pte == 0) panic("uvmclear"); *pte &= ~PTE_U; }
uvmclear清理掉stack guard page的PTE_U位，这样当访问到stack guard page时，就会触发page fault。这也是user/usertest.c下的stacktest的原理。
但是.....stack guard page真的能防止栈溢出么？
至少下面这种情况，不能。我们检查一下加载ELF LOAD段的代码，它是通过调用uvmalloc函数，确立ELF LOAD段的相关页面的虚实映射关系的。那么ELF LOAD段的权限是什么？
uint64 uvmalloc(pagetable_t pagetable, uint64 oldsz, uint64 newsz) { char *mem; uint64 a; if(newsz < oldsz) return oldsz; oldsz = PGROUNDUP(oldsz); a = oldsz; for(; a < newsz; a += PGSIZE){ mem = kalloc(); if(mem == 0){ uvmdealloc(pagetable, a, oldsz); return 0; } memset(mem, 0, PGSIZE); if(mappages(pagetable, a, PGSIZE, (uint64)mem, PTE_W|PTE_X|PTE_R|PTE_U) != 0){ kfree(mem); uvmdealloc(pagetable, a, oldsz); return 0; } } return newsz; }
用户可读可写可执行！如果栈溢出没有溢出到stack guard page上，而是溢出到了.text段上，那相当于程序直接修改了程序代码.......（人工智能进化难道就是这么完成的么？）
可能有人会认为，在执行exec时，我们可以知道ELF LOAD段的结束地址，那么把这段地址记录到进程中，作为检测栈溢出的条件不行么？
有时候行，但别忘了，ELF LOAD段还有全局变量段啊！这个段应该是可读可写的！
如果一个用户程序没有全局变量，那么可以以这个条件判断栈溢出。这也是为什么Lab4 Lazy Allocation可以通过的原因，查看user/lazytest.c的代码，它是没有全局变量的，因此代码不会访问到ELF GUARD段的内容。
我们就不要再深究这其中的安全问题了，讨论到这里只是为了能帮大家理清stack guard page到底能做什么，不能做什么。在本实验的测试代码(user/cowtest.c)中和user/usertest.c中都有对全局变量的访问：
// part of user/cowtest.c char junk1[4096]; int fds[2]; char junk2[4096]; char buf[4096]; char junk3[4096]; // test whether copyout() simulates COW faults. void filetest() { printf("file: "); buf[0] = 99; for(int i = 0; i < 4; i++){ if(pipe(fds) != 0){ printf("pipe() failed\n"); exit(-1); ...... }
因此修改代码时要十分小心对越界访问的判断。
TRAMPOLINE段和TRAPFRAME段
这两个段帮助进程实现trap。
先说简单的TRAPFRAME段。这个段用于记录进程发生trap时的现场，因此这个段必须是每个进程独有的。trapframe的物理空间分配并不是在exec或者fork中完成，而是在allocproc中就已经完成了。某个进程执行exec时，TRAPFRAME -> &p->tf 间的映射关系由proc_pagetable添加：
// kernel/exec.c
// Check ELF header if(readi(ip, 0, (uint64)&elf, 0, sizeof(elf)) != sizeof(elf)) goto bad; if(elf.magic != ELF_MAGIC) goto bad; if((pagetable = proc_pagetable(p)) == 0) // 此时TRAPFRAME -> &p->tf间的关系已经写入到pagetable中 goto bad;
TRAMPOLINE段就比较难理解了。首先要明确，TRAMPOLINE是一个虚地址，而单独讨论虚地址是没有意义的，只有这个虚地址存在到实地址的映射时，才有意义。这个映射在xv6的进程中是存在的，也是由proc_pagetable来完成添加，将所有进程的TRAMPOLINE段映射到了同一块代码区域，这块区域的代码逻辑就是/kernel/trampoline.S，即trap处理的入口。
STACK段和HEAP段
首先思考一个问题：xv6进程每个段的起始虚地址在哪里？
ELF LOAD段的虚地址是从0开始的，TRAMPOLINE段永远放在虚地址的最高处（MAXVA），占据一页，因此虚地址就是MAXVA - PGSIZE。TRAPFRAME和TRAMPOLINE是紧挨着的（它们之间有没有guard page我忘了，当没有吧），因此起始虚地址就是MAXVA - 2*PGSIZE。
那么STACK段和HEAP段的起始虚地址呢？
阅读kernel/exec.c源码后我们可以得出结论：STACK段的起始虚地址只有在加载完ELF LOAD段后才能确定。这个地址位于stack guard page的上方一页，而stack guard page也是在ELF LOAD段加载完后才确定的。
当ELF LOAD段、STACK段、stack guard page段、TRAMPOLINE段、TRAMFRAME段都确认后，中间那块剩余的区域，就是HEAP段了，也就是动态内存所处的段。查看一下kernel/proc.h中定义的进程的数据结构：
struct proc { struct spinlock lock; // p->lock must be held when using these: enum procstate state; // Process state struct proc *parent; // Parent process void *chan; // If non-zero, sleeping on chan int killed; // If non-zero, have been killed int xstate; // Exit status to be returned to parent's wait int pid; // Process ID // these are private to the process, so p->lock need not be held. uint64 kstack; // Bottom of kernel stack for this process uint64 ustackbase; uint64 sz; // Size of process memory (bytes) pagetable_t pagetable; // Page table struct trapframe *tf; // data page for trampoline.S struct context context; // swtch() here to run process struct file *ofile[NOFILE]; // Open files struct inode *cwd; // Current directory char name[16]; // Process name (debugging) };
注意到sz这个变量。对于一个进程p来说，虚地址空间[0, p->sz)，覆盖了ELF LOAD段、stack guard page段、STACK段的虚地址空间，以及当前已经分配的堆空间。
调用exec结束时，p->sz的初始值就被设定为了user stack的结尾处，即当前已分配的堆空间大小为0.
Copy-On-Write fork的引入
回顾完xv6的进程结构之后，我们可以思考一下，一个fork要完成哪些操作？
首先，必须要调用allocproc，当allocproc成功返回时，TRAMPOLINE和TRAPFRAME这两个段已经完成了初始化，因此无需处理。剩余的四个段（HEAP、STACK、STACK GUARD、ELF LOAD）都需要拷贝一份给新的进程。
这样我们会遇到以下问题：
（1）很多时候，我们调用fork，就是为了调用exec，而exec会释放掉[0, p->sz)之间的所有内容，那么[0, p->sz)这块空间，还没有被访问过一次，就被我们丢掉了。
（2）即使我们调用了fork而不调用exec，对于HEAP段的数据，大多时候的操作很可能是读操作，这个时候HEAP段完全可以和父进程共用。
（3）ELF LOAD段包含了不可写的代码段（.text），至少这个段是可以父子进程共享的。
Copy-On-Write fork的引入可以解决上述问题。当发生fork时，子进程并不会将父进程的[0, p->sz)这块空间拷贝一份留给自己，而是仅仅修改自己的进程页表，将[0, p->sz)映射到相同的实存区域，这块区域我们暂且称之为F区域。当父进程或者子进程对F区域的任意一页进行写操作时，才复制这一页。
分析与设计
Lab的主页已经告诉了我们大致的做法：
Modify uvmcopy() to map the parent's physical pages into the child, instead of allocating new pages, and clear PTE_W in the PTEs of both child and parent.
Modify usertrap() to recognize page faults. When a page-fault occurs on a COW page, allocate a new page with kalloc(), copy the old page to the new page,
and install the new page in the PTE with PTE_W set.
大致的设计如下：
（0）发生pagefault的原因有很多，可能是越界访问，也可能是访问了F区域的页面。为了能区分，我们需要给F区域的页面添加一个标志位PTE_F。若一个页面存在PTE_F位，那么这个页面一定发生了cow fork。
（1）由于存在多个虚地址映射到同一个实地址的情况，因此进程在结束后释放页面时，如果页面还在被其他进程所引用，那么就不能释放掉这个页面。为此我们需要添加数据结构，记录每个页面的引用计数。
（2）修改uvmcopy代码：
如果一个页面即没有PTE_W位也没有PTE_F位，那这个页面必定不可写，我们可以放心的让本进程引用这个页面，给它添不添加PTE_F并不会影响结果
如果一个页面存在PTE_W位，这个页面的引用计数必定为1，我们需要同时修改父子进程的相应的pte，清除掉它们的PTE_W位，替换成PTE_F位。
如果一个页面存在PTE_F位，那么就说明其它进程尚未对这个页面执行过写操作，新进程也可以放心的引用这个页面，并拷贝这个页面的权限就可以了；
（3）在trap中添加cow_handler，通过检查PTE_F位是否存在来判断是否是访问了F区域的页面。如果是，那么拷贝一份这个页面，清除这个页面的PTE_F位，重置为PTE_W位，删除掉旧页面的虚实映射关系，添加新页面到该虚地址的虚实映射关系，让旧页面的引用计数减1。
（4）在usertrap中添加了cow_handler后，我们可以处理来自用户态访问F区域页面引起的page fault。但如果用户程序是调用write来对F区域页面进行写操作时，对F区域页面的写是在内核态完成的（sys_write）。因此需要另行处理。具体方法是修改kernel/vm.c下的copyout函数，查看用户进程的页表并检查flags。
实现
（0）创立新的页表位 PTE_F:
// kernel/riscv.h
#define PTE_V (1L << 0) // valid #define PTE_R (1L << 1) #define PTE_W (1L << 2) #define PTE_X (1L << 3) #define PTE_U (1L << 4) // 1 -> user can access #define PTE_F (1L << 8) // copy-on-write flag
（1）修改kernel/kalloc.c，为每个页面添加引用计数。
我在做这一部分时脑子真的进水了。刚开始的想法是设计一个链表结构，同时记录下页面的物理地址和引用计数，然后调试起来非常复杂。后来查阅其他博客才明白，页面的物理地址本身就可以作为一个索引。修改过后调试了几次就pass了.....良好的设计可以真的可以节省不少的时间。
extern char end[]; // first address after kernel. // defined by kernel.ld. struct run { struct run *next; }; struct { struct spinlock lock; struct run *freelist; int refcount[1 << 15]; int used; } kmem; // Allocate one 4096-byte page of physical memory. // Returns a pointer that the kernel can use. // Returns 0 if the memory cannot be allocated. int pa2pageid(void* pa); void freerange(void *pa_start, void *pa_end); void* allocpage(); void freepage(void* pa); void kinit() { initlock(&kmem.lock, "kmem"); freerange(end, (void*)PHYSTOP); memset(&kmem.refcount, 0, sizeof(kmem.refcount)); kmem.used = 0; } void freerange(void *pa_start, void *pa_end) { char *p; p = (char*)PGROUNDUP((uint64)pa_start); for(; p + PGSIZE <= (char*)pa_end; p += PGSIZE) freepage(p); } // Free the page of physical memory pointed at by v, // which normally should have been returned by a // call to kalloc(). (The exception is when // initializing the allocator; see kinit above.) void kfree(void* pa) { if(((uint64)pa % PGSIZE) != 0 || (char*)pa < end || (uint64)pa >= PHYSTOP) panic("kfree"); acquire(&kmem.lock); if(decrease_ref(pa)) { kmem.used--; freepage(pa); // printf("free page %p\n", pa); } release(&kmem.lock); } void * kalloc(void) { acquire(&kmem.lock); void* page = allocpage(); if(page) { increase_ref(page, 0); } release(&kmem.lock); return page; } int pa2pageid(void* pa) { return (pa - (void*)end) / PGSIZE; } void* allocpage() { struct run* r = kmem.freelist ? kmem.freelist : 0; if(r) { kmem.used++; kmem.freelist = r->next; memset((char*)r, 5, PGSIZE); } return r; } void freepage(void* pa) { memset(pa, 1, PGSIZE); struct run* r = (struct run*)pa; r->next = kmem.freelist; kmem.freelist = r; } void increase_ref(void* pa, int exist) { int idx = pa2pageid(pa); if(exist && kmem.refcount[idx] <= 0) { printf("page %p should exist", pa); panic("increase ref"); } else if(!exist && kmem.refcount[idx] > 0) { printf("page %p should not exist", pa); panic("increase ref"); } kmem.refcount[idx]++; } int decrease_ref(void* pa) { int idx = pa2pageid(pa); if(kmem.refcount[idx] <= 0) { printf("page %p should exist"); panic("decrease ref"); } return --kmem.refcount[idx] == 0; }
（2）修改uvmcopy。fork时，仅仅修改两个进程的页表，而不申请新的内存空间：
// Given a parent process's page table, copy // its memory into a child's page table. // Copies both the page table and the // physical memory. // returns 0 on success, -1 on failure. // frees any allocated pages on failure. int uvmcopy(pagetable_t old, pagetable_t new, uint64 sz) { pte_t *pte; uint64 pa, i; uint flags; for(i = 0; i < sz; i += PGSIZE) { if((pte = walk(old, i, 0)) == 0) panic("uvmcopy: pte should exist"); if((*pte & PTE_V) == 0) panic("uvmcopy: page not present"); pa = PTE2PA(*pte); flags = PTE_FLAGS(*pte); // if PTE_W or PTE_F is set, then this page doesn't cow-fork and maybe be shared // so simply increase refcount is ok // if page could write, set PTE_F flag and clean PTE_W flag for both old and new pagetable if(*pte & PTE_F || *pte & PTE_W) { if(0 != mappages(new, i, PGSIZE, pa, (flags & (~PTE_W)) | PTE_F)) goto err; // we need also adjust page perm for parent process *pte = PA2PTE(pa) | (flags & (~PTE_W)) | PTE_F; } else { if(0 != mappages(new, i, PGSIZE, pa, flags)) goto err; } increase_ref((void*)pa, 1); } return 0; err: uvmunmap(new, 0, i, 1); // withdraw cow-fork's change on origin thread for(int j = 0; j <= i; j += PGSIZE) { pte = walk(old, j, 0); flags = PTE_FLAGS(*pte); if(flags & PTE_F) { flags = (flags & (~PTE_F)) | PTE_W; pa = PTE2PA(*pte); *pte = PA2PTE(pa) | flags; } } return -1; }
（3）在usertrap中添加cow_handler。访问F区域时发生的trap编号仍然是13或15。
我在做这个lab时犯的另一个巨大失误是把panic当做assert一样胡乱使用。panic的原意是“内核不知道自己应该怎么做”，换句话说，只有在出现“内核进入了不应该进入的状态”的情况下，才应该使用panic。大部分情况下，我们认为的“错误”是用户自己作死搞出来的，并不是内核的错，遇到这种情况应当把这个用户进程kill掉，而不是调用panic。
还有一个重大失误，算是写类似代码写多了产生的误区。我写代码的时候总是习惯“return as early as possible”，即尽早返回特殊情况。这样代码逻辑会清晰很多（最主要的是缩进会变少，我只要看到某段代码缩进超过4个心口就会隐隐作痛 →_→）。所以cow_handler刚开始的结构大概是这样的：
int cowhandler(pagetable_t pagetable, uint64 va) { if(situation1) return -1; if(situation2) return -1; ........ finally , this should be a cow-page-fault if is not a cow-page-fault { panic("not a cow-pate-fault"); } handle it }
然后跑usertest的时候，疯狂panic.....
思考后发现，这个cowhandler出现的条件是非常严格的，即相应页面必须有PTE_F位，其他情况下都应当把这个进程kill掉，而不是内核去panic。最终修改后的代码如下，如果不符合cow_handler的条件，直接返回-1，把这个进程kill掉。
// kernel/vm.c
// success return 0, failed return -1 int cow_handler(pagetable_t pagetable, uint64 va) { // return 0; if(0 == pagetable) panic("no page table\n"); // out of range access if(myproc()->sz <= va) { printf("process %d , assess %d\n", myproc()->pid, (uint64)va); printf("process size %d, stack guard %d\n", myproc()->sz, myproc()->ustackbase); printf("usertrap(): unexpected scause %p pid=%d\n", r_scause(), myproc()->pid); printf(" sepc=%p stval=%p\n", r_sepc(), r_stval()); myproc()->killed = 1; return -1; } // find corresponding pte uint64 vabase = PGROUNDDOWN(va); pte_t* pte; if((pte = walk(pagetable, vabase, 0)) == 0) panic("page should exist"); // cow pagefault situation: uint flags = PTE_FLAGS(*pte); if(!(flags & PTE_F && (flags & PTE_W) == 0)) { return -1; } // allocate a new page and recalculate it's perm void* mem = kalloc(); if(0 == mem) panic("no memory avaliable"); // free origin pte and page memmove(mem, (void*)PTE2PA(*pte), PGSIZE); kfree((void*)PTE2PA(*pte)); *pte = 0; // map it flags = (flags & (~PTE_F)) | PTE_W; if(mappages(pagetable, vabase, PGSIZE, (uint64)mem, flags)) return -1; return 0; }
将这个handler添加到usertrap中：
void usertrap(void) { int which_dev = 0; if((r_sstatus() & SSTATUS_SPP) != 0) panic("usertrap: not from user mode"); // send interrupts and exceptions to kerneltrap(), // since we're now in the kernel. w_stvec((uint64)kernelvec); struct proc *p = myproc(); // save user program counter. p->tf->epc = r_sepc(); if(r_scause() == 8){ // system call if(p->killed) exit(-1); // sepc points to the ecall instruction, // but we want to return to the next instruction. p->tf->epc += 4; // an interrupt will change sstatus &c registers, // so don't enable until done with those registers. intr_on(); syscall(); } else if((which_dev = devintr()) != 0){ // ok } else if(r_scause() == 13 || r_scause() == 15) { // printf("usertrap(): unexpected scause %p pid=%d\n", r_scause(), p->pid); // printf(" sepc=%p stval=%p\n", r_sepc(), r_stval()); if(cow_handler(myproc()->pagetable, r_stval()) != 0) { p->killed = 1; } } else { printf("usertrap(): unexpected scause %p pid=%d\n", r_scause(), p->pid); printf(" sepc=%p stval=%p\n", r_sepc(), r_stval()); vmprint(p->pagetable); p->killed = 1; } if(p->killed) exit(-1); // give up the CPU if this is a timer interrupt. if(which_dev == 2) yield(); usertrapret(); }
（4）处理内核态下对F区域页面的写操作：
其实就是修改copyout的代码，添加上对flags的检查，然后使用（3）中的cow_handler函数就可以了：
// kernel/vm.c
// Copy from kernel to user. // Copy len bytes from src to virtual address dstva in a given page table. // Return 0 on success, -1 on error. int copyout(pagetable_t pagetable, uint64 dstva, char *src, uint64 len) { uint64 n, va0, pa0; pte_t* pte; if(dstva > MAXVA) return -1; while(len > 0){ va0 = PGROUNDDOWN(dstva); pte = walk(pagetable, va0, 0); if(0 == pte) { panic("copyout : pte should exist"); } if(*pte & PTE_F) { if(cow_handler(pagetable, va0) != 0) { panic("copyout : handle cow failed"); } pa0 = walkaddr(pagetable, va0); } else { pa0 = walkaddr(pagetable, va0); } if(pa0 == 0) return -1; n = PGSIZE - (dstva - va0); if(n > len) n = len; memmove((void *)(pa0 + (dstva - va0)), src, n); len -= n; src += n; dstva = va0 + PGSIZE; } return 0; }
还有不少琐碎的地方.....就不贴上来了。这个Lab应该是近几个Lab中最简单的了。
测试全部通过：
xv6 kernel is booting virtio disk init 0 hart 2 starting hart 1 starting init: starting sh $ cowtest simple: ok simple: ok three: ok three: ok three: ok file: ok ALL COW TESTS PASSED
$ usertests usertests starting test reparent2: OK test pgbug: OK test sbrkbugs: usertrap(): unexpected scause 0x000000000000000c pid=3220 sepc=0x0000000000004430 stval=0x0000000000004430 page table 0x00000000861f5000 ..0: pte 0x0000000021882801 pa 0x000000008620a000 perm : PTE_V| .. ..0: pte 0x0000000021882c01 pa 0x000000008620b000 perm : PTE_V| ..255: pte 0x0000000021fd1001 pa 0x0000000087f44000 perm : PTE_V| .. ..511: pte 0x0000000021882401 pa 0x0000000086209000 perm : PTE_V| .. .. ..510: pte 0x00000000218830c7 pa 0x000000008620c000 perm : PTE_V|PTE_R|PTE_W| .. .. ..511: pte 0x000000002000204b pa 0x0000000080008000 perm : PTE_V|PTE_R|PTE_X| usertrap(): unexpected scause 0x000000000000000c pid=3221 sepc=0x0000000000004430 stval=0x0000000000004430 page table 0x00000000861e2000 ..0: pte 0x0000000021877c01 pa 0x00000000861df000 perm : PTE_V| .. ..0: pte 0x0000000021878001 pa 0x00000000861e0000 perm : PTE_V| .. .. ..0: pte 0x00000000216d2d1b pa 0x0000000085b4b000 perm : PTE_V|PTE_R|PTE_X|PTE_U|PTE_F| ..255: pte 0x0000000021878c01 pa 0x00000000861e3000 perm : PTE_V| .. ..511: pte 0x0000000021876c01 pa 0x00000000861db000 perm : PTE_V| .. .. ..510: pte 0x00000000218830c7 pa 0x000000008620c000 perm : PTE_V|PTE_R|PTE_W| .. .. ..511: pte 0x000000002000204b pa 0x0000000080008000 perm : PTE_V|PTE_R|PTE_X| OK test badarg: OK test reparent: OK test twochildren: OK ........ test sbrkarg: OK test validatetest: OK test stacktest: OK test opentest: OK test writetest: OK test writebig: OK test createtest: OK test openiput: OK test exitiput: OK test iput: OK test mem: OK test pipe1: OK test preempt: kill... wait... OK test exitwait: OK test rmdot: OK test fourteen: OK test bigfile: OK test dirfile: OK test iref: OK test forktest: OK test bigdir: OK ALL TESTS PASSED
