将博客的正式入口从 blog.wendaining.top 换成了 blog.wendain.ing，实际内容改由 Cloudflare Pages 托管。同时保留 wendaining.github.io，仅仅指向 GitHub Pages，使之继续作为一份可以直接访问的镜像，同时也是适应原来的工作流。

原来的工作流不变：文章等内容仍然放在 Blog-Source 分支。每次向这个分支提交，GitHub Actions 和 Cloudflare Pages 会分别构建并发布同一份 Hexo 博客。

为什么要迁移

最主要的原因是买了新域名一直没用（这个确实很cool啊x

之前博客完全托管在 GitHub Pages 上，域名 blog.wendaining.top 也直接指向 wendaining.github.io。GitHub 在部分网络环境下访问并不稳定。

所以这次没有放弃 GitHub Pages，而是增加 Cloudflare Pages 作为正式站点：日常访问默认落到 Cloudflare，GitHub Pages 则保留为备用镜像。

我之前写过的基于 GitHub Actions 部署 Hexo 博客的 workflow仍然继续工作。

迁移过程中做了什么

建立 Cloudflare Pages

Cloudflare Pages 直接连接同一个 GitHub 仓库，并监听 Blog-Source 分支。构建配置和 GitHub Actions 保持一致：

• Node.js 22；
• 执行 npm ci && npx hexo generate；
• 发布 public 目录。

这样一来，一次提交会触发两条彼此独立的流水线：GitHub Actions 把静态文件发布到 main，Cloudflare Pages 则自行构建并发布到 Cloudflare。

重新整理域名

现在的域名关系如下：

• blog.wendain.ing：正式域名，由 Cloudflare Pages 提供内容；
• blog.wendaining.top：永久重定向到新域名，文章路径和查询参数都会保留；
• wendaining-blog.pages.dev：同样永久重定向到正式域名；
• wendaining.github.io：保留为可直接访问的 GitHub Pages 镜像。

现在的架构

flowchart TD    A["向 Blog-Source 提交文章或配置"]    B["GitHub Actions 构建"]    C["Cloudflare Pages 构建"]    D["main 分支：生成后的静态文件"]    E["wendaining.github.io<br/>GitHub Pages 镜像"]    F["blog.wendain.ing<br/>Cloudflare Pages 正式站"]    G["blog.wendaining.top"]    H["wendaining-blog.pages.dev"]    A --> B    A --> C    B --> D    D --> E    C --> F    G -->|301| F    H -->|301| F

产生的影响

日常访问统一到了 Cloudflare

从旧域名进入时，Cloudflare 会在边缘直接返回 301，然后浏览器访问 blog.wendain.ing。旧域名不再加载完整博客页面，也不会先绕到 GitHub Pages 再跳一次。

搜索引擎相关的站点 URL、Open Graph 和 RSS/Atom 元数据也已经改成新域名。

发布流程基本没有变化

写文章时仍然只需要修改 Blog-Source。区别只是以前一次提交只有 GitHub Actions 构建，现在 Cloudflare Pages 也会同时构建。两边是独立流水线，因此更新时可能有几十秒的先后差异；只要两次构建都成功，最终内容就是一致的。

最后

目前这个结构比较舒服：正常访问走 Cloudflare，GitHub Pages 不再承担主站流量，但仍然保留着一份随时可以访问和回退的静态博客。

参考的资料：

Gorse 推荐系统入门：从零到一构建推荐引擎 - 技术漫游 - 博客园

gorse-io/gorse | DeepWiki

主页 | Gorse

入门

什么是推荐系统

三个要素：

• 记录行为
• 理解兴趣
• 预测可能喜欢

启动与使用

直接使用 docker 启动（参阅官方文档）。

基于 Web 的，直接访问 localhost:8088 可以浏览。

使用 curl 进行插入数据、创建物品、插入反馈、获取推荐等。

核心工作原理的概述

四个核心概念：

• 用户
  • 基础信息：ID、标签等（如年龄、性别）
  • 行为历史：浏览、点击、购买...
• 物品
  • 基础信息：ID、标签
  • 统计数据：热度、评分
• 反馈
  • 用户+物品+类型+时间
• 推荐
  • 根据历史行为预测用户可能喜欢的物品

流程图：

1. 用户产生行为
2. 系统记录反馈
3. 模型定期执行分析、训练
4. 生成推荐
5. 用户看到推荐
6. 循环迭代，回到 1

Gorse 的推荐策略：多源融合。

1. 协同过滤：找到相似用户，推荐他们喜欢的物品
2. 物品相似：推荐和用户历史物品相似的其他物品
3. 热门推荐：推荐最热门的物品
4. 最新推荐：字面意思

所谓融合策略：推荐结果 = 30% 协同过滤 + 30% 物品相似 + 20% 热门推荐 + 20% 最新推荐

Gorse 的架构设计

三层架构：

flowchart TD    A["用户 / 应用<br/>Web · App · 小程序"]    B["Server 节点<br/>RESTful API + 实时推荐"]    C["Master 节点<br/>模型训练 + 任务调度 + Dashboard"]    D["Worker 节点（多个）<br/>离线计算 + 批量推荐"]    E["存储层<br/>MySQL + Redis<br/>用户数据 + 物品数据 + 推荐缓存"]    A -->|HTTP / HTTPS| B    B -->|gRPC| C    C -->|gRPC| D    D --> E

Server  ──gRPC──>  MasterMaster  ──gRPC──>  Worker

GetModel(name string) Model

model := master.GetModel("ranking")

model, err := client.GetModel(ctx, request)

Server  │  │ 调用 GetModel(...)  ↓gRPC Client  │  │ 序列化成 Protobuf  │ 通过 HTTP/2 发送  ↓网络  ↓Master 上的 gRPC Server  │  │ 反序列化  ↓真正执行 GetModel(...)

Master 节点

可以理解为 Gorse 架构的大脑。

• 模型训练
• AutoML： Automated Machine Learning（自动机器学习）
• 任务调度，触发 Worker
• Dashboard：监控、数据管理

Worker 节点

理解为 Gorse 架构的手脚。

• 批量推荐：为每个用户生成推荐列表
• 相似度计算：计算物品之间的相似，计算用户之间的相似度
• 水平扩展：启动多个 Worker，负载均衡

Server 节点

理解为「嘴巴」。

• 提供 RESTful API
• 实时推荐
• 在线更新

综合

flowchart LR    A["用户行为"] --> B["Server"]    B --> C["DataStore<br/>MySQL"]    C --> D["Master<br/>定期加载数据"]    D --> E["训练模型"]    E --> F["Worker<br/>计算推荐"]    F --> G["CacheStore<br/>Redis"]    G --> H["Server"]    H --> I["返回用户"]    %% 局部调整布局    subgraph Train[" "]        direction TB        D --> E    end    subgraph Recommend[" "]        direction TB        F --> G    end

理解 Gorse 的管道（pipeline）

管道 | Gorse

• 数据源输入输入层之后，传入检索层
• 检索层由多个推荐器构成，为用户生成候选物品
• 排序层合并来自不同推荐器的所有输出，删除用户已经看过的物品（已读物品），并根据用户与剩余物品互动的可能性对其进行评分

默认的管道是只推荐最新物品。

管道中的缓存

以下中间结果被缓存并定期更新：

• 用户到用户推荐器的用户邻居。
  • 简单来说，用户 A 的相似用户是 B C D，那么这个结果会被缓存
• 物品到物品推荐器的物品邻居。
  • 和上面同理，相似物品缓存
• 非个性化推荐器的结果。
  • 和具体用户没有太大关系的内容，比如说最新榜、热门榜
• 每个用户的排序器输出
  • 就是最后排序器输出的结果

Gorse 工作原理

管道以分布式方式执行。Gorse 中有三种类型的节点：主节点、工作节点和服务器节点。也就是上面说的 Master Worker Server，不再赘述。

深入 Gorse 推荐系统：数据结构与存储层设计剖析

深入 Gorse 推荐系统：数据结构与存储层设计剖析 - 技术漫游 - 博客园

我感觉也是这个作者的 AI 文章自己洗了一遍...总之大概看看吧。

字符串->索引的映射

显然我们会有大量的 JSON（也可以是 Go 里面的 map[string][]），里面都是字符串作为 key。

字符串作为 key，效率很低（主要是哈希比较带来的开销是 $O(len(string))$

感觉最难的 lab...起码是代码量最大的。

阅读

事实上这就是 Lab5 COW 里面提到的 8.1 Page Fault Basics | MIT6.S081 这一章节里面所涉及的内容（一个小节）。所以需要读的内容也不多，只是一种机制。

memory mapped files 的核心思想是将完整或部分文件加载到内存中，从而直接使用内存的 load store 来操控文件，减少了磁盘 I/O。

需要实现的接口（来自 man 2 mmap）：

void *mmap(void *addr, size_t len, int prot, int flags,           int fd, off_t offset);           int munmap(void *addr, size_t len);

这个 lab 不要求完全实现 POSIX 里面的规定，可以做出如下简化问题的假设：

对于 mmap()：

• addr 总是 0，表示由 kernel 决定映射到哪个虚拟地址。

• mmap 成功时返回映射地址，失败时返回 0xffffffffffffffff。

• len 表示要映射的字节数，它可能和文件长度不同。

• prot 表示这段内存是否可读、可写和/或可执行。这个 Lab 中只需要处理 PROT_READ、PROT_WRITE 或两者组合。

• flags 只会是 MAP_SHARED 或 MAP_PRIVATE。

• MAP_SHARED 表示对映射内存的修改应该写回文件。

• MAP_PRIVATE 表示修改不应该写回文件。

• fd 是待映射文件的已打开 file descriptor。

• offset 可以假设总是 0，即总是从文件开头开始映射。

• 关于懒分配：这里采用的是懒分配模式。也就是说，mmap() 本身不应该分物理内存，也不应该读取文件。只有当 page fault 发生时，再在 usertrap() 或它调用的 page fault 处理代码里完成真正的分配和文件读取。

  回忆 cow lab

• 如果两个进程映射同一个 MAP_SHARED 文件，这个 Lab 允许它们 不共享同一个 physical page。

关于 munmap()：

• 删除指定范围内的 mmap 映射。
• 如果进程已经修改过这段内存，并且对应的是 MAP_SHARED 映射，那么在解除映射之前，修改应该先写回文件。
• 本来可能是只解除整个 mmap 映射中的一部分（从中间挖洞）（回忆拆 super page），但是这个 lab 是要么开头要么结尾要么整个，总之不会只在中间。

实现

依旧以 hints 为线索。

建立系统调用

还是老一套流程。

为每个进程记录 mmap 区域

建立每进程的 struct vma，即 Virtual Memory Area，虚拟内存区域，记录 mmap() 创建的虚拟地址范围信息。

// kernel/proc.hstruct vma {  int valid;  uint64 addr;  uint64 len;  uint64 offset;  int prot;  int flags;  struct file *f;};

offset len 不使用和原来签名一样的类型。

原因是 size_t 和 off_t 属于 mmap 接口类型，目前定义在 defs.h；但很多源文件会先包含 proc.h、后包含 defs.h，导致解析 struct vma 时还不认识它们。

uint64 定义在更基础的 types.h 中，而且在 xv6 里：

• size_t 实际就是 64 位无符号整数；
• 本实验的 offset 固定为 0，不需要 off_t 的有符号语义；
• 虚拟地址、长度和文件偏移本身也适合用 uint64 保存。

因此，用户接口和 sys_mmap() 参数仍按照 man page 使用：

size_t len;off_t offset;

而 VMA 是内核内部数据结构，用 uint64 保存转换后的数值即可。两层不要求使用完全相同的类型名称，只需数值能正确表示。

然后，由于 xv6 kernel 中没有 variable-size kernel allocator，直接声明一个固定大小（16）的 VMA 数组，需要时从里面分配。

// kernel/def.h#define NVMA 16

// kernel/proc.cstruct vma vma[NVMA];

实现 mmap()

首先要理解 mmap 的映射区域到底位于虚拟地址空间的哪些部分：

地址空间可以大致理解为：

低地址┌──────────────────────┐│ 程序代码、数据、堆      │├──────────────────────┤ ← 原来的 p->sz┤│ 尚未使用的地址空间      │├──────────────────────┤ ← limit / TRAPFRAME│ TRAPFRAME            │├──────────────────────┤│ TRAMPOLINE           │└──────────────────────┘ ← MAXVA高地址

mmap 区域不能覆盖最上面的两个特殊页面。

一开始（以及读到的知乎文章 MIT XV6 操作系统 实验全解 - 知乎 ）里面的实现是这样的：

uint64sys_mmap(void){  void *addr;  size_t len;  int prot, flags, fd;  off_t offset;  struct file *f;  struct proc *p = myproc();  argaddr(0, (uint64 *)&addr);  argaddr(1, &len);  argint(2, &prot);  argint(3, &flags);  argaddr(5, (uint64 *)&offset);  // This lab only supports kernel-selected addresses and mappings that  // start at the beginning of a regular file.  if(addr != 0 || len == 0 || offset != 0) {    return -1;  }  if((prot & ~(PROT_READ | PROT_WRITE)) != 0 ||     (prot & (PROT_READ | PROT_WRITE)) == 0) {      return -1;  }  if(flags != MAP_SHARED && flags != MAP_PRIVATE) {    return -1;  }  // 将 fd 对应的文件对应到 struct file *f 上  if(argfd(4, &fd, &f) < 0 || f->type != FD_INODE || !f->readable) {    return -1;  }  if(flags == MAP_SHARED && (prot & PROT_WRITE) && !f->writable) {    return -1;  }  // 为 mmap 选择一段虚拟地址进行映射，  // p->sz 是目前的进程能用到的最高的地址空间，将新映射放在它后面  addr = (void *)PGROUNDUP(p->sz);  uint64 limit = MAXVA - 2 * PGSIZE;  // leave TRAPFRAME/TRAMPOLINE untouched  if((uint64)addr >= limit || len > limit - (uint64)addr) {    return -1;  }  // 长度round up到最近的页面字节数  size_t maplen = PGROUNDUP(len);  int idx;  for(idx = 0; idx < NVMA; idx++){    if(!p->vma[idx].valid) {      break;    }  }  if(idx == NVMA) {    return -1;  }  struct vma *vma = &p->vma[idx];  vma->valid = 1;  vma->addr = (uint64)addr;  vma->len = len;  vma->permissions = prot;  vma->offset = offset;  vma->prot = prot;  vma->flags = flags;  vma->f = filedup(f);  p->sz = (uint64)addr + maplen;  return (uint64)addr;}

vma 如果按照答主的实现，从 p->sz 之后一路往上分配，在 2025 版的 lab （这个答主是 Fall 2020 版本）里面测试会不通过，然后大致理由是：

• 由于 mmap 和 munmap 的触发时机不同以及目前寻找 vma 都是下标分配，事实上每个 vma 的 addr 及其下标会不存在正相关的关系，而且事实上难以管理 p->sz ，只能任凭其增长，无法缩小。
• 那么，假设我们 munmap 了某个 vma，会产生类似内部碎片的东西；
• 测试数据里面，这一块已经被 munmap 的部分，如果再触发 page fault，由于其满足 va < p->sz，并且并不处于 vma 的范围内，会被判定为由 sbrk() 产生的 lazy allocation 页，再度分配实际的物理页框；
• 但是，测试数据是：解除某页的映射之后再度读取，预期触发非法访问杀死进程。这里显然不满足了

所以我们实际上应该换一种分配 vma 的方式，我想到了从 MAXVA - 2*PGSIZE 也就是蹦床页往下两页开始倒着分配。

在 struct proc 里面添加一个 uint64 mmap_top;，表示下一次分配 vma 的起始处。因为虚拟地址近乎是无穷大的，这样不会对 OS 产生影响。

所以大致的实现是这样的：

uint64sys_mmap(void){  void *addr;  size_t len;  int prot, flags, fd;  off_t offset;  struct file *f;  struct proc *p = myproc();  argaddr(0, (uint64 *)&addr);  argaddr(1, &len);  argint(2, &prot);  argint(3, &flags);  argaddr(5, (uint64 *)&offset);  // This lab only supports kernel-selected addresses and mappings that  // start at the beginning of a regular file.  if(addr != 0 || len == 0 || offset != 0) {    return -1;  }  if((prot & ~(PROT_READ | PROT_WRITE)) != 0 ||     (prot & (PROT_READ | PROT_WRITE)) == 0) {      return -1;  }  if(flags != MAP_SHARED && flags != MAP_PRIVATE) {    return -1;  }  // 将 fd 对应的文件对应到 struct file *f 上  if(argfd(4, &fd, &f) < 0 || f->type != FD_INODE || !f->readable) {    return -1;  }  if(flags == MAP_SHARED && (prot & PROT_WRITE) && !f->writable) {    return -1;  }  // 为了防止从 p->sz 开始分配，结果因为创建/销毁 vma 的顺序不同，导致 p->sz 没有可能正确回收的问题  // 不使用 p->sz 开始分配的方法，而是从顶上开始倒着分配  // 因为虚拟地址近乎是无穷大的，这样不会对 OS 产生影响  // #define MMAPTOP (MAXVA - 2 * PGSIZE)  if(len > MMAPTOP) {    return -1;  }  size_t maplen = PGROUNDUP(len);  if(maplen > p->mmap_top) {    return -1;  }  uint64 mapaddr = p->mmap_top - maplen;  if(mapaddr < PGROUNDUP(p->sz)) {    return -1;  }  addr = (void *)mapaddr;  int idx;  for(idx = 0; idx < NVMA; idx++){    if(!p->vma[idx].valid) {      break;    }  }  if(idx == NVMA) {    return -1;  }  struct vma *vma = &p->vma[idx];  vma->valid = 1;  vma->addr = (uint64)addr;  vma->len = maplen;  vma->offset = offset;  vma->prot = prot;  vma->flags = flags;  vma->f = filedup(f);  p->mmap_top = (uint64)addr;  return (uint64)addr;}

务必注意，mmap() 里面没有真的分配页，是要落实到 page fault 发生时才真的分配的。

这里就只是，记录下来这个文件（通过传入 fd）应该映射到这个特定的 VMA 这里。

处理 mmap page fault

添加代码，让 mmap region 中发生 page fault 时：

1. 分配一个物理页；
2. 从文件中读取相关的 PGSIZE 到该页；
3. 把该页映射进用户地址空间。

使用 readi() 读取文件。

int readi(struct inode *ip, int user_dst, uint64 dst, uint off, uint n);

根据 cow lab 的经验，这里应该是修改 vmfault() 函数。

代码：

uint64vmfault(pagetable_t pagetable, uint64 va, int read){  uint64 mem;  struct proc *p = myproc();  if(va >= MAXVA) {    return 0;  }  va = PGROUNDDOWN(va);  if(ismapped(pagetable, va)) {    return 0;  }  int index = ismmaped(p, va);  if(index != -1) {    struct vma *vma = &p->vma[index];    struct inode *ip = vma->f->ip;    // mem 是 kalloc() 返回的内核地址    if((mem = (uint64)kalloc()) == 0) {      return 0;    }    memset((void *)mem, 0, PGSIZE);    ilock(ip);    // va - vma->addr = 当前产生 page fault 的页面与 vma 开始地址的距离    // 看似没保证页对齐，但是 vma->offset 永远是 0，而前两者已经页对齐，所以无妨    uint64 fileoff = (va - vma->addr) + vma->offset;    if(readi(ip, 0, mem, fileoff, PGSIZE) == -1) {      iunlock(ip);      kfree((void *)mem);      return 0;    }    int flags = PTE_U;    if(vma->prot & PROT_READ) {      flags |= PTE_R;    }    if(vma->prot & PROT_WRITE) {      flags |= PTE_R | PTE_W;    }    if(mappages(pagetable, va, PGSIZE, mem, flags) != 0) {      iunlock(ip);      kfree((void *)mem);      return 0;    }    iunlock(ip);    return mem;  }  // Only addresses below p->sz belong to the ordinary lazy-allocation area.  // A high address removed by munmap must remain invalid.  if(va >= p->sz) {    return 0;  }  mem = (uint64) kalloc();  if(mem == 0) {    return 0;  }  memset((void *) mem, 0, PGSIZE);  if (mappages(p->pagetable, va, PGSIZE, mem, PTE_W|PTE_U|PTE_R) != 0) {    kfree((void *)mem);    return 0;  }  return mem;}

这里面比较麻烦的点在于这个 fileoff，但其实就是计算偏移。

另外，注意 flags。

另外：

实现 munmap()

最难的一个小题。

系统调用的函数签名：

int munmap(void *addr, size_t len);

addr 和 len 都是虚拟地址（虚拟地址空间的 VMA 部分）。

重点在于不需要处理部分挖洞的情况。也就是，只需要考虑这样的情况：

spec 说得不是很详细，但是我认为可以跨 VMA 处理，同时因为 VMA 是一直往前分配的，也就是这样：

这样的情况只是可能存在。

于是我就考虑，从 addr 开始，计算需要释放的字节范围窗口，然后一边释放一边缩小窗口，每次循环，都遍历所有的 vma 进行扫描，按照 addr 所在的地方来进行判断。（但是每轮循环只处理一个，扫到了就处理这个）。

得到了之后，通过不断的比较，确定是哪种情况（头 or 尾），然后再确定具体而言需要处理的范围。

之后，在这个范围内，一页一页地处理：

• 如果 vma->flags == MAP_SHARED，那么就需要执行写回的操作

  • 计算 fileoff，也就是文件内的偏移量。因为是要写回文件，但是文件内部的调整是通过 inode 结构体的偏移量实现的，这里需要手动指定

    为什么不能完全处理，因为解映射可以是只解除一部分的。

  • 写回文件，具体写多少也是个问题。默认来说，我们一次是写一页（因为是一页一页地处理）。但是，有时候末尾可能有不足一页的部分，这个时候 write_len 就变成了最后剩下的长度。

    上面的部分需要获取 ip->size，就算是读取也需要上 inode 锁。

  • 最后，写回。 spec 里面说，要参考 filewrite()，但是这里有问题，因为 filewrite() 的文件内偏移量无法自己指定。具体而言见下面的部分，总之写一个 filewriteat() 辅助函数，可以指定偏移量。

  • 最后，如果正好是释放了一整个 vma，那么还需要减少文件的 ref（fileclose(f)），再清空掉这个 vma。

• 最后记得修改窗口。

最核心的逻辑，因为会发现后面的 kexit() 的修改，需要做和 munmap() 一样的事情，所以提取出来，作为一个传参的函数，放在 vm.c 里面。

// kernel/sysfile.cuint64sys_munmap(void){  uint64 addr;  size_t len;  argaddr(0, &addr);  argaddr(1, &len);  return vmaunmap(myproc(), addr, len);}

// kernel/vm.cintvmaunmap(struct proc *p, uint64 addr, uint64 len){  addr = PGROUNDDOWN(addr);  len = PGROUNDUP(len);  if(len == 0 || addr + len < addr) {    return -1;  }  while(len > 0) {    struct vma *vma = 0;    // Re-scan because VMA slot order need not match virtual-address order.    for(int idx = 0; idx < NVMA; idx++) {      struct vma *cand = &p->vma[idx];      if(cand->valid && addr >= cand->addr &&         addr - cand->addr < cand->len) {        vma = cand;        break;      }    }    if(vma == 0) {      return -1;    }    struct file *f = vma->f;    struct inode *ip = f->ip;    uint64 vma_end = vma->addr + vma->len;    uint64 unmap_end = addr + len;    uint64 free_end = unmap_end < vma_end ? unmap_end : vma_end;    uint64 free_len = free_end - addr;    for(uint64 pageva = addr; pageva < free_end; pageva += PGSIZE) {      pte_t *pte = walk(p->pagetable, pageva, 0);      if(pte == 0 || (*pte & PTE_V) == 0) {        continue;      }      if(vma->flags == MAP_SHARED && (vma->prot & PROT_WRITE)) {        uint64 pa = PTE2PA(*pte);        uint64 fileoff = vma->offset + (pageva - vma->addr);        uint write_len = PGSIZE;        ilock(ip);        if(fileoff >= ip->size) {          write_len = 0;        } else if(write_len > ip->size - fileoff) {          write_len = ip->size - fileoff;        }        iunlock(ip);        if(write_len > 0 &&           filewriteat(f, 0, pa, fileoff, write_len) != write_len) {          return -1;        }      }      uvmunmap(p->pagetable, pageva, 1, 1);    }    if(addr == vma->addr && free_end == vma_end) {      fileclose(f);      memset(vma, 0, sizeof(*vma));    } else if(addr == vma->addr) {      vma->addr += free_len;      vma->len -= free_len;      vma->offset += free_len;    } else if(free_end == vma_end) {      vma->len -= free_len;    } else {      panic("vmaunmap: hole");    }    addr = free_end;    len -= free_len;  }  return 0;}

为什么需要 filewriteat()

这里的问题主要有两个：文件内的偏移量和源地址的类型。

首先看 filewrite() 最关键的部分：

if ((r = writei(f->ip, 1, addr + i, f->off, n1)) > 0) {  f->off += r;}

filewrite() 没有接收文件偏移量的参数，它使用的是 struct file 内部的 f->off。每写入一段数据，还会自动把 f->off 往后推进。这对普通的 write() 是正确的，因为普通文件读写本来就需要维护一个当前读写位置。

但 mmap 写回文件时，文件位置不能由 f->off 决定，而是由这张页在 VMA 内的位置决定：

fileoff = vma->offset + (pageva - vma->addr);

例如，假设映射从文件偏移 0 开始，现在要解映射 VMA 的第 2 页：

VMA 第 0 页  ────▶  文件 offset 0VMA 第 1 页  ────▶  文件 offset 4096VMA 第 2 页  ────▶  文件 offset 8192

这时必须把该页写到文件的 8192 处。但 f->off 可能是 0，也可能已经被普通的 read() / write() 改到了其他位置。而且 filedup() 只是增加原来 struct file 的引用计数，VMA 和 fd 指向的仍然是同一个 struct file，所以不能假设 f->off 始终等于 mmap 需要的位置。

于是把 filewrite() 中写 inode 文件的逻辑提取成 filewriteat()：

intfilewriteat(struct file *f, int user_src, uint64 src, uint64 off, int n);

最后的调用是：

filewriteat(f, 0, pa, fileoff, write_len);

其中：

• 0 表示是 pa 不是 va；

  其实这里（vmunmap()）传 va 也可以（就是循环里面的 pageva），但是都一样。

• pa 是当前需要写回的物理页；

• fileoff 是这张页在文件内的正确位置；

• write_len 是这次实际允许写入的长度。

filewriteat() 仍然保留 filewrite() 里面的分批写入、文件系统事务和 inode 加锁逻辑，但它使用显式传入的 off，并且不读取、不修改 f->off。

修改 kexit()

就是释放所有 VMA，和 munmap() 一样。

// munmap all mmap regionsfor(int i = 0; i < NVMA; i++) {    struct vma *vma = &p->vma[i];    if(vma->valid) {      if(vmaunmap(p, vma->addr, vma->len) < 0) {        panic("kexit: vmaunmap");      }    }}

修改 kfork()

也就是复制一下，和复制 trapframe 没什么本质区别。hints 也提示了需要给文件引用 +1，照做就行了。

for (int i = 0; i < NVMA; ++i) {    struct vma* vma = &p->vma[i];    struct vma* nvma = &np->vma[i];    *nvma = *vma;    if (nvma->valid) {      filedup(nvma->f);    }}

关于 challenges

其实我觉得这几个都挺有意思的，但是有点累了，在这里如果之后有兴趣，回来实现一下。

写完会发现自己对于 xv6 的日志以及事务系统好像就没什么了解，只有在 file system 的 lab 里面简单操作了一下诸如 bread() brelse() 这样的简单 API，但是没有像 inode 这样深入了解，这也是个 TODO 吧。

简单读一下书，让 GPT 翻译并提炼重点，然后读对应的部分。

xv6 将文件系统分为 7 层：

• Disk layer：真正向 VirtIO disk 读写 block。
• Buffer cache：把磁盘 block 缓存在内存，并保证一个 block 同一时间只有一个线程修改。
• Logging：把多个 block 的修改组成 transaction，保证 crash 后要么全部生效，要么全部不生效。
• Inode：把一个文件表示成 inode + 若干 data block。
• Directory：目录其实是一种特殊文件，内容是一系列 name -> inode number。
• Pathname：解析 /a/b/c。
• File descriptor：最终向用户提供 open/read/write/... 这样的统一接口。

所谓「crash consistency 崩溃一致性」：崩溃的时候，修改 inode，记录日志等工作完成到一半，导致不一致。xv6 的实现方式是日志，不直接修改正式文件系统，先把这次 transaction 的修改写进 log。

关于日志的设计，位于磁盘的特定区域。

inode 分磁盘上的 struct dinode 和内存里的 struct inode。内存 inode 只是磁盘 inode 的缓存副本

磁盘 inode 的重要字段：

typenlinksizeaddrs[]

含义：

• type：普通文件、目录、device……
• nlink：有多少 directory entry 指向它。
• size：文件大小。
• addrs[]：文件数据所在的 disk block number。

inode number（inum）就是 inode 在磁盘 inode 区域中的编号。

内存中的 struct inode 额外拥有：

reflockvalid...

ref 表示当前 kernel 中有多少 C 指针正在引用这个 inode。

然后有区分 direct blocks 和 indirect 的，也就是一级索引和二级索引：

然后查询 inode 和目录也是一堆 API，比如对于一个完整的路径，依据分隔符进行分割然后递归查询逐层的 inode 的 namex() 。

Large files

根据 hints 来：

分析 bmap() 函数

// Return the disk block address of the nth block in inode ip.// If there is no such block, bmap allocates one.// returns 0 if out of disk space.static uintbmap(struct inode *ip, uint bn){  uint addr, *a;  struct buf *bp;  if(bn < NDIRECT){    if((addr = ip->addrs[bn]) == 0){      addr = balloc(ip->dev);      if(addr == 0)        return 0;      ip->addrs[bn] = addr;    }    return addr;  }  bn -= NDIRECT;  if(bn < NINDIRECT){    // Load indirect block, allocating if necessary.    if((addr = ip->addrs[NDIRECT]) == 0){      addr = balloc(ip->dev);      if(addr == 0)        return 0;      ip->addrs[NDIRECT] = addr;    }    bp = bread(ip->dev, addr);    a = (uint*)bp->data;    if((addr = a[bn]) == 0){      addr = balloc(ip->dev);      if(addr){        a[bn] = addr;        log_write(bp);      }    }    brelse(bp);    return addr;  }  panic("bmap: out of range");}

• 「阅读」部分的图 10.3 十分十分重要。
• bn 是 logical block number，即相对于文件开头而言，这个 block 是文件中的第几个 block。返回的是实际的 disk block number。
• 若 bn < NDIRECT，根据图片所示，直接映射到 ip->addrs[bn] 处的数据块。
  • 但是实际实现是先检查是否存在，如果不存在还得 balloc() 分配一个出来。
• 若 bn > NDIRECT：
  1. 先 bn -= NDIRECT，这一步是为了把原本在整个文件范围内的逻辑块号，转变为一级间接块数组内的下标
     • 事实上看图也能看出来进入一级块之后就又是 address 1 ~ 256 了，不过实际上应该是 0 ~ 255。
  2. 检查 bn < NINDIRECT，事实上就是检查之前的 bn 在不在最大范围内（ MAXFILE = NDIRECT + NINDIRECT)
  3. 检查通过后，检查间接块的存在性，没有就分配
  4. 然后，首先通过 bread() 获取磁盘上的这个 block 的间接块的 struct buf，获取里面的数据。
     1. 如果数据为空，继续分配，不空就直接获得地址，可以直接返回了（不过是代码的写法上没这么写，逻辑等价）
     2. 确认非空之后，给 a[bn] 里面映射上刚分配好的块，再记录日志
     3. 最后释放掉，然后返回这个地址

修改宏定义

目前 xv6 的文件最多只能有 268 blocks，分析一下原因，是因为规定了 #define NDIRECT 12，并且 dinode 和 inode 里面有 uint addrs[NDIRECT+1];。

也就是，12 个直接块号，以及 1 个一级间接块号。

又规定 BSIZE 1024（块的字节数），sizeof(uint) = 4 ，故一个间接块号至多存 256 个 block number，故 MAXFILE = 12 + 256 = 268 blocks。

这个 lab 需要实现 doubly-indirect block，变成了 $256^2 + 256 + 11 = 65803 \text{blocks}$

#define NDIRECT 11#define NINDIRECT (BSIZE / sizeof(uint))#define NINDIRECT2 (NINDIRECT * NINDIRECT)#define MAXFILE (NDIRECT + NINDIRECT + NINDIRECT2)

然后，修改 struct inode 和 struct dinode 字段：

uint addrs[NDIRECT+2];

思考清楚计算方式

思考：给定一个文件的 logical block number，应该怎样计算它在 doubly-indirect block 中的位置，也就是先选第几个 singly-indirect block，再选其中第几个 data block。

这边偷一张知乎上的图，画的很好：

具体而言，如果 bn 是位于二级索引的位置：

• 首先是需要先减去前面两个部分（其实计算的过程中逐步减掉了）

• 然后，2nd indirect 里面的每一个 address，都映射到了另一个 1st indirect，也就是另外的 256 个实际的 data block

• 那么，举个例子，bn = 45162（随便打的符合要求的数字）

  • 经过一级和二级的判断，bn = 45162 - 11 - 256 = 44895
  • 然后，整除 256，得到 175，也就是位于第 175 个一级索引
  • 然后，44895 % 256 = 95，也就是位于这个一级索引指向的第 95 个 data block

这就是计算方式。

实现对 bmap() 的修改

static uintbmap(struct inode *ip, uint bn){  uint addr, *a;  struct buf *bp;  if(bn < NDIRECT){    if((addr = ip->addrs[bn]) == 0){      addr = balloc(ip->dev);      if(addr == 0)        return 0;      ip->addrs[bn] = addr;    }    return addr;  }  bn -= NDIRECT;  if(bn < NINDIRECT){    // Load indirect block, allocating if necessary.    if((addr = ip->addrs[NDIRECT]) == 0){      addr = balloc(ip->dev);      if(addr == 0)        return 0;      ip->addrs[NDIRECT] = addr;    }    bp = bread(ip->dev, addr);    a = (uint*)bp->data;    if((addr = a[bn]) == 0){      addr = balloc(ip->dev);      if(addr){        a[bn] = addr;        log_write(bp);      }    }    brelse(bp);    return addr;  }  // 以下为实现代码  bn -= NINDIRECT;  if(bn < NINDIRECT2) {    // 这里的 addr 是二级间接块的地址    if ((addr = ip->addrs[NDIRECT + 1]) == 0) {      addr = balloc(ip->dev);      if (addr == 0) {        return 0;      }      ip->addrs[NDIRECT + 1] = addr;    }    // 这里的 bp 是二级间接块的实际 struct buf    bp = bread(ip->dev, addr);    a = (uint*)bp->data;    // 这里的 addr 是二级间接块指向的一级间接块的地址    if ((addr = a[bn / NINDIRECT]) == 0) {      addr = balloc(ip->dev);      if (addr == 0) {        return 0;      }      a[bn / NINDIRECT] = addr;      // 记得任何对于实际 buf 的修改都要落日志，维护崩溃一致性      log_write(bp);    }    brelse(bp);    // 这里的 bp 是一级间接块的实际的 struct buf    bp = bread(ip->dev, addr);    a = (uint*)bp->data;    // 这里的 addr 是最后实际的数据的地址    if ((addr = a[bn % NINDIRECT]) == 0) {      addr = balloc(ip->dev);      if (addr == 0) {        return 0;      }      a[bn % NINDIRECT] = addr;      log_write(bp);    }    brelse(bp);    return addr;  }  panic("bmap: out of range");}

其实很多地方是重复利用了一个变量，比如 bp 和 a 和 addr，这是因为原本的代码就是这样的重复利用，虽然不清晰，不过为了保持代码风格一致，就这样吧。

记得对每一个通过 bread() 读取的 block，都不要忘记最终调用 brelse()。

修改 itrunc()

不要忘记修改 itrunc()，确保它能够释放文件的所有 block，包括 double-indirect block 及其下层 block。

就像改了 kalloc() 加一级，那也肯定是要修改 kfree() 的。

voiditrunc(struct inode *ip){  int i, j, k;  struct buf *bp;  uint *a;  for(i = 0; i < NDIRECT; i++){    if(ip->addrs[i]){      bfree(ip->dev, ip->addrs[i]);      ip->addrs[i] = 0;    }  }  if(ip->addrs[NDIRECT]){    bp = bread(ip->dev, ip->addrs[NDIRECT]);    a = (uint*)bp->data;    for(j = 0; j < NINDIRECT; j++){      if(a[j])        bfree(ip->dev, a[j]);    }    brelse(bp);    bfree(ip->dev, ip->addrs[NDIRECT]);    ip->addrs[NDIRECT] = 0;  }  if(ip->addrs[NDIRECT + 1]) {    bp = bread(ip->dev, ip->addrs[NDIRECT + 1]);    a = (uint*)bp->data;    for(j = 0; j < NINDIRECT; j++) {      uint in1_addr;      if ((in1_addr = a[j]) != 0) {        struct buf *in1_bp = bread(ip->dev, in1_addr);        uint *in1_a = (uint*)in1_bp->data;        for(k = 0; k < NINDIRECT; k++) {          bfree(ip->dev, in1_a[k]);        }        brelse(in1_bp);        bfree(ip->dev, in1_addr);      }    }    brelse(bp);    bfree(ip->dev, ip->addrs[NDIRECT + 1]);    ip->addrs[NDIRECT + 1] = 0;  }  ip->size = 0;  iupdate(ip);}

Symbolic links

给 xv6 添加符号链接 / 软链接功能，也就是实现系统调用 symlink。

复习一下，所谓的软链接，就是一个记录目标路径名的 alias。这么理解区别：

hard link：name → inodesymbolic link：name → symlink inode → pathname → inode

这个 lab 里面不需要处理指向目录的软链接。

以 hints 为线索：

添加和系统调用相关的基础配置

为 symlink 创建一个新的 system call number：

// kernel/syscall.h#define SYS_symlink 22

在 kernel/sysfile.c 里面实现空的 sys_symlink()：

uint64sys_symlink(void){  }

在 kernel/syscall.cl 下面声明、加入系统调用的数组：

extern uint64 sys_symlink(void);static uint64 (*syscalls[])(void) = {[SYS_fork]    sys_fork,// ...[SYS_symlink] sys_symlink,};

在 user/usys.pl 里面加入对应的 entry：

entry("symlink");

在 user/user.h 里面加入声明：

int symlink(char *target, char *path);

加入新的标识文件类型

// kernel/stat.h#define T_DIR     1   // Directory#define T_FILE    2   // File#define T_DEVICE  3   // Device#define T_SYMLINK 4   // soft link

添加新的 flag

#define O_RDONLY   0x000#define O_WRONLY   0x001#define O_RDWR     0x002#define O_CREATE   0x200#define O_TRUNC    0x400#define O_NOFOLLOW 0x20000

这主要是给 open 用的（RTFM 得知这个 flag 是这个数）

根据 man：

If the trailing component (i.e., basename) of pathname is a symbolic link, then the open fails, with the error ELOOP

实现 symlink()

在 path 创建新的 symbolic link 并让它指向 target，注意 target 不需要真实存在。

这里我一开始搞不懂这些 API 和概念（读书不仔细），然后我就考虑读一下 sys_link() 的实现：

// Create the path new as a link to the same inode as old.uint64sys_link(void){  char name[DIRSIZ], new[MAXPATH], old[MAXPATH];  struct inode *dp, *ip;  if(argstr(0, old, MAXPATH) < 0 || argstr(1, new, MAXPATH) < 0)    return -1;  begin_op();  if((ip = namei(old)) == 0){    end_op();    return -1;  }  ilock(ip);  if(ip->type == T_DIR){    iunlockput(ip);    end_op();    return -1;  }  ip->nlink++;  iupdate(ip);  iunlock(ip);  if((dp = nameiparent(new, name)) == 0)    goto bad;  ilock(dp);  if(dp->dev != ip->dev || dirlink(dp, name, ip->inum) < 0){    iunlockput(dp);    goto bad;  }  iunlockput(dp);  iput(ip);  end_op();  return 0;bad:  ilock(ip);  ip->nlink--;  iupdate(ip);  iunlockput(ip);  end_op();  return -1;}

梳理出一些要点：

1. begin_op() 和 end_op() 开启文件系统的事务，保证 ACID
2. namei() 返回路径对应的文件的 inode 结构体指针
3. 得到了 inode 指针之后，如果想做修改，还需要使用 ilock() 进行加锁，再使用 iunlock() 解锁，修改之后需要使用 iupdate 进行落盘，把内存 inode 写回磁盘上的 struct dinode

但其实只能知道这些，然后读书（其实是问 LLM 要点）可以得到这些额外的信息：

1. create() 给出的 inode 是直接带锁的，不需要自己加锁
2. 软链接是通过创建一个类型为 T_SYMLINK 的 inode，里面的 data block（实际是 inode 的 addr 所指向的 buf （通过 bmap() 求得）的 uchar data[BSIZE];） 是 target 来实现的。
3. 因此，如果想读写，是有对应的 API 的，也就是readi() 和 writei()，这个的用法直接 Ctrl + F 一下就能看懂了。

但是实际上理解也有偏颇，还需要读 create()，这里直接给出 LLM 的纠错版：

上面的误会也导致了我开始的错误实现（包括 open()）

因此给出 symlink() 的实现：

uint64sys_symlink(void){  char path[MAXPATH], target[MAXPATH];  struct inode *ip;  if(argstr(1, path, MAXPATH) < 0 || argstr(0, target, MAXPATH) < 0) {    return -1;  }  begin_op();  // 这段代码不需要，`create()` 自己会检查目标路径是否已存在  // if (namei(path) != 0) {  //   end_op();  //   return -1;  // }  ip = create(path, T_SYMLINK, 0, 0);  if (ip == 0) {    end_op();    return -1;  }    int len = strlen(target) + 1;  if (writei(ip, 0, (uint64)target, 0, len) != len) {    end_op();    return -1;  }  // iupdate(ip); 不需要，writei() 有  iunlockput(ip);  end_op();  return 0;}

修改 open()

因为如果 open() 传入的 path 实际上只是一个符号链接，肯定不能直接返回符号链接的 inode 对应的 fd，而应该返回其指向的 target 所对应的。这里加上特殊处理即可。

uint64sys_open(void){  char path[MAXPATH];  int fd, omode;  struct file *f;  struct inode *ip;  int n;  argint(1, &omode);  if((n = argstr(0, path, MAXPATH)) < 0)    return -1;  begin_op();  if(omode & O_CREATE){    ip = create(path, T_FILE, 0, 0);    if(ip == 0){      end_op();      return -1;    }  } else {    if((ip = namei(path)) == 0){      end_op();      return -1;    }    ilock(ip);    // 目录检查放在展开之后  }  // ========  int depth = 0;  while (ip->type == T_SYMLINK && omode != O_NOFOLLOW) {    char target[MAXPATH];    if (readi(ip, 0, (uint64)target, 0, MAXPATH) <= 0) {      iunlockput(ip);      end_op();      return -1;    }    iunlockput(ip);    if ((ip = namei(target)) == 0) {      end_op();      return -1;    }    ilock(ip);    depth++;    if (depth > 10) {      iunlockput(ip);      end_op();      return -1;    }  }  if(ip->type == T_DIR && omode != O_RDONLY){    iunlockput(ip);    end_op();    return -1;  }  // ========  if(ip->type == T_DEVICE && (ip->major < 0 || ip->major >= NDEV)){    iunlockput(ip);    end_op();    return -1;  }  if((f = filealloc()) == 0 || (fd = fdalloc(f)) < 0){    if(f)      fileclose(f);    iunlockput(ip);    end_op();    return -1;  }  if(ip->type == T_DEVICE){    f->type = FD_DEVICE;    f->major = ip->major;  } else {    f->type = FD_INODE;    f->off = 0;  }  f->ip = ip;  f->readable = !(omode & O_WRONLY);  f->writable = (omode & O_WRONLY) || (omode & O_RDWR);  if((omode & O_TRUNC) && ip->type == T_FILE){    itrunc(ip);  }    iunlock(ip);  end_op();  return fd;}

这里可能存在的问题是不知道该在哪里插入，我的建议是分析一下 xv6 一共有的这些 flags 分别对应的情况，然后照着分支去分析

另：一开始的错误实现

uint64sys_symlink(void){  char path[MAXPATH], target[MAXPATH];  struct inode *ip;  if(argstr(0, path, MAXPATH) < 0 || argstr(1, target, MAXPATH) < 0) {    return -1;  }  begin_op();  if (namei(path) != 0) {    end_op();    return -1;  }  ip = create(path, T_SYMLINK, 0, 0);  if (ip == 0) {    end_op();    return -1;  }    if (writei(ip, 0, (uint64)target, 0, MAXPATH) < 0) {    end_op();    return -1;  }  iupdate(ip);  iunlock(ip);  end_op();  return 0;}uint64sys_open(void){  char path[MAXPATH];  int fd, omode;  struct file *f;  struct inode *ip;  int n;  argint(1, &omode);  if((n = argstr(0, path, MAXPATH)) < 0)    return -1;  begin_op();  if(omode & O_CREATE){    ip = create(path, T_FILE, 0, 0);    if(ip == 0){      end_op();      return -1;    }  } else {    if((ip = namei(path)) == 0){      end_op();      return -1;    }    ilock(ip);    if(ip->type == T_DIR && omode != O_RDONLY){      iunlockput(ip);      end_op();      return -1;    }  }  // ========  ip = namei(path);  if (ip == 0) {    end_op();    return -1;  }  ilock(ip);  int depth = 0;  while (ip->type == T_SYMLINK && omode != O_NOFOLLOW) {    char target[MAXPATH];    if (readi(ip, 0, (uint64)target, 0, MAXPATH) < 0) {      iunlockput(ip);      end_op();      return -1;    }    iunlockput(ip);    if ((ip = namei(target)) == 0) {      end_op();      return -1;    }    ilock(ip);    depth++;    if (depth > 10) {      iunlockput(ip);      end_op();      return -1;    }  }  // ========  if(ip->type == T_DEVICE && (ip->major < 0 || ip->major >= NDEV)){    iunlockput(ip);    end_op();    return -1;  }  if((f = filealloc()) == 0 || (fd = fdalloc(f)) < 0){    if(f)      fileclose(f);    iunlockput(ip);    end_op();    return -1;  }  if(ip->type == T_DEVICE){    f->type = FD_DEVICE;    f->major = ip->major;  } else {    f->type = FD_INODE;    f->off = 0;  }  f->ip = ip;  f->readable = !(omode & O_WRONLY);  f->writable = (omode & O_WRONLY) || (omode & O_RDWR);  if((omode & O_TRUNC) && ip->type == T_FILE){    itrunc(ip);  }  iunlock(ip);  end_op();  return fd;}

简单读一下书吧，让 GPT 翻译并提炼重点，然后读对应的部分。

并发的来源：

• 多核 CPU
• 线程切换
• 中断

回顾概念：

• 竞态条件
• 临界区

减少锁的竞争：这个 ostep 也有阐述。给整个数据结构加一把大锁固然能解决问题，但是效率低。

关于锁的源码：kernel/spinlock.h kernel/spinlock.c

关于 spinlock 自旋锁

struct spinlock {  uint locked; // 0 表示没被持有  char *name;  struct cpu *cpu;};

关于得锁，RISC-V 提供原子指令 amoswap，原子地完成读取内存-寄存器写入内存-返回旧值，也就是 acquire() 的实现。释放锁是类似的思想和原理。

Lab 的重点是对 kalloc() 进行优化，把锁的颗粒度拆细。

需要防止死锁。

xv6 的实现里面，只要有任何自旋锁被持有，就关闭 CPU 中断。

acquire() 内部调用：

push_off();

关闭中断。

release() 最后调用：

pop_off();

恢复中断。

关于 sleeplock：因为 spinlock 不能中断，才引入。

使用 acquiresleep() 让出 CPU，内部使用一个 spinlock 进行保护，之后可以 wakeup。

Memory allocator

大致是有一个 kalloctest.c，里面会高强度进行锁竞争（反复调用 kalloc() free()）。

根本原因是kalloc() 只有一个 free list，并且这个 free list 由一个全局锁保护。

减少锁竞争的基本思路是重新设计内存分配器，因此本 lab 的任务是为每个 CPU 单独维护一个 free list，并给每个 list 配一个自己的锁。

所以这个 lab 必须在有多核 CPU 的机器上做。

一个主要难点是某个 CPU 的 free list 已经空了，但另一个 CPU 的 free list 中还有空闲内存，这个时候，缺少内存的 CPU 需要去其他 CPU 的 free list 里面获取一些空闲页面，也就是所谓的 stealing。

现在着手实现：

首先是需要修改 kmem，就是原来空闲链表的结构体（一个 freelist 里面带一个锁）：

原来：

struct {  struct spinlock lock;  struct run *freelist;} kmem;

修改成支持多 CPU 的形式：

struct {  struct spinlock lock[NCPU];  struct run *freelist[NCPU];} kmem;

然后修改 kinit() 等，总之要使用到当前运行的 CPU。

这里首先需要知道获取当前运行的 CPU 的 API，这里 hint 3 也有说，不过还是问 LLM ：

所以 kfree() 和 kalloc() 这样改：

voidkfree(void *pa){  struct run *r;  if(((uint64)pa % PGSIZE) != 0 || (char*)pa < end || (uint64)pa >= PHYSTOP)    panic("kfree");  // Fill with junk to catch dangling refs.  memset(pa, 1, PGSIZE);  r = (struct run*)pa;  push_off();  int id = cpuid();  acquire(&kmem.lock[id]);  r->next = kmem.freelist[id];  kmem.freelist[id] = r;  release(&kmem.lock[id]);  pop_off();}void *kalloc(void){  struct run *r;  push_off();  int id = cpuid();  acquire(&kmem.lock[id]);  r = kmem.freelist;  if(r)    kmem.freelist[id] = r->next;  release(&kmem.lock[id]);  pop_off();  if(r)    memset((char*)r, 5, PGSIZE); // fill with junk  return (void*)r;}

但是这样还没有实现 stealing。

修改 kalloc()：

void *kalloc(void){  struct run *r;  push_off();  int id = cpuid();  acquire(&kmem.lock[id]);  r = kmem.freelist[id];  if(r)    kmem.freelist[id] = r->next;  release(&kmem.lock[id]);  if (r == 0) {    for (int i = 0; i < NCPU; ++i) {      // 找到序号最小的有空余页的空闲列表      if (i == id) {        continue;      }      acquire(&kmem.lock[i]);      if (kmem.freelist[i]) {        r = kmem.freelist[i];        kmem.freelist[i] = r->next;      }      release(&kmem.lock[i]);      if (r) {        break;      }    }  }  pop_off();  if(r)    memset((char*)r, 5, PGSIZE); // fill with junk  return (void*)r;}

然后可以通过所有测试。

Read-write lock

考虑 xv6 中的：

sys_pause()sys_uptime()

这两个函数都会读取全局变量 ticks。

但是 ticks 会同时被 clockintr() 更新，所以两个函数读取 ticks 之前会获取 tickslock。但是其实只需要持写锁就行了，完全没必要设读相关的锁。这个 lab 就是区分读者和写者。

复习一下 ostep 的内容，读写者问题里面，规则是：

• 同一时间最多只能有 一个 writer；
• 存在 writer 时，不能存在 reader；
• 如果没有 writer，则可以同时存在 多个 reader。
• 为了防止 reader 一直读导致 writer 饿死，设置 writer priority，即一旦有 writer 开始尝试获取锁，那么之后到来的 reader 必须等待，直到这个 writer 成功获得锁并释放它。

read-write lock API (in kernel/defs.h)：

void initrwlock(struct rwspinlock*);void read_acquire(struct rwspinlock*);void read_release(struct rwspinlock*);void write_acquire(struct rwspinlock*);void write_release(struct rwspinlock*);

本 lab 需要补全 kernel/spinlock.c 中 read-write spinlock API 对应的 stub 函数，以及修改 kernel/spinlock.h 中的 struct rwspinlock 定义。

hints 说要读 sys_rwlktest() 函数了解测试用例，其实大概就是一直验证读和写（上述的四条规则）。

从测试可以反推，这个锁至少需要记录：

• 读者数
• 当前是否有 active reader
• 当前 waiting writer 的数量

同时，需要保证状态的转换都是原子的。

// Reader-writer lock.struct rwspinlock {  struct spinlock l; // state lock  int readers;  int waiting_writers;  int is_writer_active;};

hints 说：

如果你什么都不修改，直接在 xv6 中运行 rwlktest，内核会打印：

panic: acquire

原因是原有 spinlock 的实现只允许某一时刻由一个 thread 持有锁。

你需要替换：

write_acquire_innerwrite_release_innerread_acquire_innerread_release_inner

中对 acquire() 和 release() 的调用，改为你自己的锁实现。

实现的部分：

static voidread_acquire_inner(struct rwspinlock *rwlk){  while (1) {    acquire(&rwlk->l);    if (rwlk->is_writer_active == 0 && rwlk->waiting_writers == 0) {      rwlk->readers++;      release(&rwlk->l);      return;    }    release(&rwlk->l);  }}static voidread_release_inner(struct rwspinlock *rwlk){  while (1) {    acquire(&rwlk->l);    if (rwlk->readers > 0) {      rwlk->readers--;      release(&rwlk->l);      return;    }    release(&rwlk->l);  }}static voidwrite_acquire_inner(struct rwspinlock *rwlk){  // 首先这个肯定不能放到循环里面，其次这个务必要加锁  acquire(&rwlk->l);  rwlk->waiting_writers++;  release(&rwlk->l);  while (1) {    acquire(&rwlk->l);    if (rwlk->readers == 0 && rwlk->is_writer_active == 0) {      rwlk->waiting_writers--;      rwlk->is_writer_active = 1;      release(&rwlk->l);      return;    }    release(&rwlk->l);  }}static voidwrite_release_inner(struct rwspinlock *rwlk){  while (1) {    acquire(&rwlk->l);    if (rwlk->is_writer_active) {      rwlk->is_writer_active = 0;      release(&rwlk->l);      return;    }    release(&rwlk->l);  }}

2 个注意点：

1. 务必要加循环，因为是一直去尝试获得，考虑到这是自旋锁
   • 我开始是读了 ostep 的实现读写锁的部分没看到，我后面才意识到人家是用的信号量机制，而信号量机制底层还是读写锁。我们实现的这些数据，其实就有点像是实现了一个信号量机制。
2. write_acquire_inner(*struct* rwspinlock **rwlk*) 函数，waiting_writers 变量的添加，肯定是要放在循环外面并且是函数开头的，因为这表示了开始等待，而自旋空转就是等待的过程。其次显然要加锁，这里开始忘记加了，test8过不去。

中断 Interrupt：硬件需要得到 OS 的关注，产生一个中断，过程与系统调用类似。但是不同点：

• 异步，与当前 CPU 运行的进程无关
• 并行，设备与 CPU 并行运行
• 需要驱动程序

许多设备驱动都会在两个不同的上下文中执行代码：

• top half（上半部）：运行在某个进程的内核线程中。
• bottom half（下半部）：在发生中断时执行，也就是中断处理程序。

Part One：NIC

网络栈已经准备好了一个装有完整数据包的内存 buffer（存放数据包 packets 的），我们需要做的是补全两个函数。

一些陌生名词的解释：

• NIC Network Interface Card 网卡，E1000 也是网卡的一种

• DMA Direct Memory Access 直接内存访问：

  • 一般而言，硬件不能直接操纵内核内存
  • 但是配置好 DMA 之后，E1000 可以直接读写指定的内存，也就是 buffer
  • 这样，CPU 就不需要自己搬运数据

• Descriptor 描述符，主要是告诉网卡，数据包的位置、长度、以及别的信息，代码里面是 tx_desc

  descriptor├── addr：buffer 的内存地址├── length：数据包长度├── status：网卡是否处理完成└── cmd：要求网卡执行什么操作

  • TX descriptor：描述「需要发送的数据包」。
  • RX descriptor：描述「用来接收数据包的空 buffer」。

• Descriptor Ring 因为描述符的数量不够，所以是一个回环，题目里面是 0~15

• Control register，驱动通过控制寄存器来通知 E1000 相关的操作，具体而言，是 regs[]

• TDT Transmit Descriptor Tail，可以理解为「TX ring 中，驱动下一次应该填写哪个 descriptor」

• RDT Receive Descriptor Tail，「驱动已经处理完并重新交还给 E1000 的最后一个 RX descriptor」

• DD Descriptor Done，descriptor 的 status 字段中的一个标志位

  • TX 的 DD 表示 E1000 已经把这个 descriptor 对应的数据包发送完，也不再读取它的 buffer
  • RX 的 DD 表示 E1000 已经收到一个数据包，并将它完整写入这个 descriptor 指向的 buffer

• EOP End Of Packet 数据包的结尾

• RS Report Status

• net_rx() xv6 网络栈接收数据包的入口

首先是补全 e1000_transmit()：

inte1000_transmit(char *buf, int len){  acquire(&e1000_lock);  uint32 index = regs[E1000_TDT];  struct tx_desc *desc = &tx_ring[index];  if((desc->status & E1000_TXD_STAT_DD) == 0){    release(&e1000_lock);    return -1;  }  if(desc->addr != 0)    kfree((void *)desc->addr);  desc->addr = (uint64)buf;  desc->length = len;  desc->cmd = E1000_TXD_CMD_EOP | E1000_TXD_CMD_RS;  desc->status = 0;  regs[E1000_TDT] = (index + 1) % TX_RING_SIZE;  release(&e1000_lock);  return 0;}

根据上面的概念和 hints，即可完成。

然后是 e1000_recv()，同理完成即可。

Part Two: UDP Receive

这个 part 里面，spec 给得更加详细了。照着读就行，甚至不需要读别的手册。

照着 hints 一步一步来：

1. 创建数据结构

Create a struct to keep track of bound ports and the packets in their queues.

定义两个：

• udp_packet 表示队列中的一个数据包
• udp_port 表示一个已经绑定的端口，同时记录下一个端口，从而形成链表，依此可以检查端口是否分配

使用端口对象池分配绑定端口：

#define UDP_PORTS_PER_PAGE 12struct udp_port_page {  struct udp_port ports[UDP_PORTS_PER_PAGE];  int used;  struct udp_port_page *next;};

sys_bind() 的实现：检查传入端口号，然后检查是否绑定，没有就分配，然后加入 ports 链表。

ip_rx() 的实现：检查收到的包，然后找对应的端口。

sys_recv() 的实现：根据hint跑即可。

另：有个试着获得 mit pdos 官网 DNS 的测试，如果开着梯子的一些特殊设置似乎过不去，然后我就试着关掉梯子 / 系统代理 / TUN 连环关掉测试...最后得到的结果是：打开系统代理，关闭 TUN 即可。

记得修改代理之后，还需要重启 WSL 才能应用。

这个 lab 的 guidance 罕见地没有给出任何 Reading xv6 book 的指示。但是我还是看一看课程的文档：8.1 Page Fault Basics | MIT6.S081

这一章节事实上涵盖了原本有的 Lazy Allocation Lab, Copy on-write Lab, 以及 mmap lab。

这里只简单概述一下 Copy on-write 的思想：

一个进程 fork 之后，创建的是父进程的一个完整拷贝。在目前的实现中，是直接复制物理空间；而如果 fork 之后还立刻执行 exec，则这个地址空间还会被丢弃，很浪费。

cow 的思想就是子进程和父进程的虚拟地址空间映射到同一个物理地址，但是 PTE 设置为只读。如果有写操作发生（无论是父还是子进程执行的写），则触发 page fault，拷贝相应的页，PTE 设置为可读写，再继续执行。

将一个页标记为 cow 页，使用的是 PTE 的最后一个 bit。

同时，由于之前的实现中不存在一个物理地址对应多个虚拟地址这样的映射，导致进程结束时的释放也会存在问题。解决方案是对物理页框添加引用计数。

Implement copy-on-write fork

其实 lab 这里对于什么是 copy on-write 的说明都很清晰了，比课程文档还清晰易懂一点。

根据提供的步骤，一步一步来即可，不过需要先实现一些基础设施（也就是 hint 的内容）：

为 PTE 记录 COW 映射

在 riscv.h 里面

#define PTE_COW (1L << 8)

之后改 flags 的时候里面随便改。

修改 uvmcopy()

这个函数原本的作用是在创建子进程时，把父进程的页表完全拷贝进新进程（在 Page table Lab 里面分析得很清楚了）。

这里需要：不要再为子进程分配新的物理页面并复制数据，改成直接把父进程的物理页面映射进子进程页表，并且将父进程和子进程的页中的 PTE_W 都清空。

intuvmcopy(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)      continue;   // page table entry hasn't been allocated    if((*pte & PTE_V) == 0)      continue;   // physical page hasn't been allocated    pa = PTE2PA(*pte);    flags = PTE_FLAGS(*pte);    if(flags & PTE_W) {      flags &= ~PTE_W;      flags |= PTE_COW;      *pte = PA2PTE(pa) | flags;    }    if(mappages(new, i, PGSIZE, pa, flags) != 0)      goto err;  }  // TODO: 是否要刷新 TLB？留待之后分析  return 0; err:  uvmunmap(new, 0, i / PGSIZE, 1);  return -1;}

修改 vmfault() 处理 COW page fault

关于 vmfault() 函数的作用，参考 Page table Lab 里面就有说明，主要是和 Lazy Alloaction 相关的。

目前的 vmfault() 函数，read 参数是没有用到的，我猜测作用是区分不同 page fault 的类型，询问 LLM 得到的答案：

然后我大致有思路但是有点懒得自己手敲（实则是不太会），喂给 LLM 这样的 prompt：

关于修改 vmfault 的这步，我大概是有个思路了：首先，如果是read=1，就和原来的逻辑一模一样去进行处理；如果是read=0，那么首先检查这个页面，检查页面的方式是walk() 一下找到 pte 然后检查 flags，然后 kalloc 分配一个新的物理页面，修改原来pte的flags（主要是write部分，顺便去掉cow），然后复制，最后让 pte 指向这个新的页面。因为只有原本设置为可写的页面才会被打上cow的标记，所以不需要做是否可写的判定。但是我脑子里有点难以组织这个逻辑如何和现有的懒分配的逻辑进行耦合，所以请你直接帮我修改一下这个代码，顺便讲解一下。

代码实现：

uint64vmfault(pagetable_t pagetable, uint64 va, int read){  uint64 mem, pa;  uint flags;  pte_t *pte;  struct proc *p = myproc();  if (va >= p->sz)    return 0;  va = PGROUNDDOWN(va);  if(ismapped(pagetable, va)) {    pte = walk(pagetable, va, 0);    if(read || (*pte & PTE_U) == 0 || (*pte & PTE_COW) == 0)      return 0;    pa = PTE2PA(*pte);    flags = PTE_FLAGS(*pte);    mem = (uint64)kalloc();    if(mem == 0)      return 0;    memmove((void *)mem, (void *)pa, PGSIZE);    flags = (flags | PTE_W) & ~PTE_COW;    *pte = PA2PTE(mem) | flags;    return mem;  }  mem = (uint64) kalloc();  if(mem == 0)    return 0;  memset((void *) mem, 0, PGSIZE);  if (mappages(p->pagetable, va, PGSIZE, mem, PTE_W|PTE_U|PTE_R) != 0) {    kfree((void *)mem);    return 0;  }  return mem;}

几个核心点：

• va >= p->sz 和 ismapped() 检查的是两个完全不同的问题：

  • va >= p->sz：这个虚拟地址在不在进程合法的地址范围内？
  • ismapped()：这个合法虚拟地址目前有没有对应的物理页面？

• 原本的懒分配逻辑是，检查是否 ismapped()，如果有映射说明是存在对应的物理页面的，无视。但是目前需要耦合 COW 的逻辑，而且 COW 页一定是存在对应的物理页的（考虑到 uvmcopy 的逻辑就是建立虚拟页对实际存在的物理页的映射，循环使用了 mappages() ），因此，这里 COW 的逻辑，就全部落在了原本直接 return 0 的 ismapped 部分。

• 这里继续检查，如果是只读，或者不是 COW 页，或者 (*pte & PTE_U) == 0 即用户模式下不允许访问此页（如 trampoline 页等）也就直接返回掉。

• 然后，获取这个页对应的所有信息，和我之前给的 prompt 不同，首先复制旧页面，然后计算新 flags，最后才替换 PTE，这是为了防止 kalloc() 失败，原来的有效映射也可能被破坏。

• 所谓的 flags 只有虚拟页也就是 pte 才有，物理页是没有的！

• 之后 COW 部分的逻辑就结束了，其余的丢给懒分配的逻辑。

实现物理页面引用计数

必须确保每个物理页面只在最后一个 PTE 引用消失后才被释放。

我开始认为，维护引用计数的规则：

• kalloc() 分配页面时，初始化置 1
• fork() 让子进程共享物理页面时，引用计数 +1，虽然说是 fork()，但是实际上是在 uvmcopy() 里面实现，和下面的 uvmunmap() 对应。
• 某个进程从页表中移除此页面（uvmunmap()）时，引用计数 -1。
• kfree() 的逻辑：只有当引用计数为 0 时，才能放回空闲列表。
• 所谓的物理地址，也就是 pa。由于物理页框地址总是 PGSIZE 对齐的，可以使用 pa / PGSIZE 作为数组的下标，记录某个页的引用计数（实际上，这个数字就是第几个物理页框）。数组的大小，就是利用 PHYSTOP 就行了。
• 这里务必需要注意一点，这个数组不能随意修改，最好是加一把锁，然后通过设置好的函数 krefinc() krefdec() 进行加减访问，防止并发冲突。

但是实际上存在几个问题：

• krefdec() 其实不应该存在，而是把引用数的削减全部放在 kfree() 里面。因为解除虚拟页和物理页的引用的地方远远不止 uvmunmap() 一处。比如 vmfault() 就直接把旧的物理页改成了新的物理页，相当于是解引用，但是没有经过 uvmunmap()。但是无论如何，这里都相当于是减少了引用计数。
  • 因此，这里需要修改 kfree() 的语义。应当是，先负责引用计数 -1，然后检查，如果真的减到 0 了，才执行释放（放回空闲列表中）。
• int phy_ref[PHYSTOP / PGSIZE]; 比较浪费，不如用 int phy_ref[(PHYSTOP - KERNBASE) / PGSIZE]，然后写一个 index 的映射函数。
• freerange() 需要特殊处理，因为 freerange() 开始的时候页面的初始计数都是 0，但是 kfree() 会搞成 -1，所以先赋值为 1

摘一些核心的代码：

#define NPAGE ((PHYSTOP - KERNBASE) / PGSIZE)struct {  struct spinlock lock;  int count[NPAGE];} kref;static intpaindex(uint64 pa){  return (pa - KERNBASE) / PGSIZE;}voidfreerange(void *pa_start, void *pa_end){  char *p;  p = (char*)PGROUNDUP((uint64)pa_start);  for(; p + PGSIZE <= (char*)pa_end; p += PGSIZE){    // kfree() drops a reference, so give each boot-time page one    // reference before adding it to the free list.    acquire(&kref.lock);    kref.count[paindex((uint64)p)] = 1;    release(&kref.lock);    kfree(p);  }}voidkfree(void *pa){  struct run *r;  if(((uint64)pa % PGSIZE) != 0 || (char*)pa < end || (uint64)pa >= PHYSTOP)    panic("kfree");  int index = paindex((uint64)pa);  acquire(&kref.lock);  if(kref.count[index] < 1)    panic("kfree: no reference");  kref.count[index]--;  if(kref.count[index] > 0){    release(&kref.lock);    return;  }  release(&kref.lock);  // Fill with junk to catch dangling refs.  memset(pa, 1, PGSIZE);  r = (struct run*)pa;  acquire(&kmem.lock);  r->next = kmem.freelist;  kmem.freelist = r;  release(&kmem.lock);}voidkrefinc(uint64 pa){  if((pa % PGSIZE) != 0 || (char*)pa < end || pa >= PHYSTOP)    panic("krefinc");  int index = paindex(pa);  acquire(&kref.lock);  if(kref.count[index] < 1)    panic("krefinc: free page");  kref.count[index]++;  release(&kref.lock);}

修改 copyout()

首先解析一下 copyout() 是什么：

// 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)

从这个函数签名可以看出，作用是把内核空间中的数据，安全地复制到某个进程的用户虚拟地址中。

目前的 copyout() 的逻辑，有关于 lazy allocation 的处理逻辑：

pa0 = walkaddr(pagetable, va0);if(pa0 == 0) {  if((pa0 = vmfault(pagetable, va0, 0)) == 0) {    return -1;  }}

如果这个用户地址尚未映射，当前代码会尝试通过 vmfault() 分配页面。

但是目前还无法正确处理 COW 逻辑，因为 COW 页没有 PTE_W，但是实际上是可写的，只是要模拟一次写 pagefault，其实就是调用一次 vmfault()即可。

intcopyout(pagetable_t pagetable, uint64 dstva, char *src, uint64 len){  uint64 n, va0, pa0;  pte_t *pte;  int needfault;  while(len > 0){    va0 = PGROUNDDOWN(dstva);    if(va0 >= MAXVA) {      goto err;    }    needfault = 0;    pa0 = walkaddr(pagetable, va0);    if(pa0 == 0){      needfault = 1;    } else {      pte = walk(pagetable, va0, 0);      if((*pte & PTE_W) == 0){        if((*pte & PTE_COW) == 0) {          goto err;        }        needfault = 1;      }    }// 这里运用了布尔语句的短路特性    if(needfault && (pa0 = vmfault(pagetable, va0, 0)) == 0) {      goto err;    }          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; err:  return -1;}

通过所有测试：

做这个 lab 中的一些感触：最好还是选择 Fall 2020 / Fall 2021 版本的，别选 2025 的。因为中文互联网上关于这门课的资料集中于前两个版本，各种源码分析也是。

阅读

本来是看录课的，但是发现自己看不太进去，遂又转向读文档。

归纳一下比较重要的机制：

mode

supervisor mode 相比 user mode 只有两个特殊权限：

• 可以读写控制寄存器
• 可以使用 PTE_U 标志位为 0 的 PTE。当 PTE_U 标志位为1的时候，只有用户代码可以使用这个页表；如果这个标志位为 0，则只有 supervisor mode 可以使用这个页表

没有的权限/设定：

• 不能读写任意物理地址，像普通的用户代码一样，也需要通过 page table 来访问内存
• trap 机制不控制 kernel 查看寄存器的内容，只是保存

一些重要的寄存器

• 如SATP（Supervisor Address Translation and Protection）寄存器，它包含了指向page table的物理内存地址（详见4.3）。
• 如STVEC（Supervisor Trap Vector Base Address Register）寄存器，它指向了内核中处理trap的指令的起始地址。
• SEPC（Supervisor Exception Program Counter）寄存器，在trap的过程中保存程序计数器的值。

ecall

ecall 是 RISC-V 提供的一个系统指令，执行：

• 将代码从 user mode 改到 supervisor mode
• 将程序计数器的值保存在了 SEPC 寄存器
• 跳转到 STVEC 寄存器指向的指令（所谓的跳转就是把 PC 指向这里）

对于 xv6 而言，STVEC 就是指向 trampoline page，包含 trap 处理代码。

ecall并不会切换page table，这是ecall指令的一个非常重要的特点。所以这意味着，trap处理代码必须存在于每一个user page table中。因为ecall并不会切换page table，我们需要在user page table中的某个地方来执行最初的内核代码。而这个trampoline page，是由内核小心的映射到每一个user page table中，以使得当我们仍然在使用user page table时，内核在一个地方能够执行trap机制的最开始的一些指令。

ecall 执行的东西很少，这是 RISC 的体现。

uservec

用于保存用户寄存器的汇编函数。

基本来说，就是每个进程都有一个 trapframe结构体，对应每个 user page table 有一个 trapframe page（在 syscall lab 中见过了），把所有寄存器定义了一遍。汇编的函数实现也就是一堆 sd ra, 40(a0) 的存储。

但是在这之前，还需要做一件事情：

• 在进入到 user space 之前，内核会将 trapframe page 的地址 0x3fffffe000 保存在 SSCRATCH 这个寄存器中
• uservec 的第一行，执行 csrrw a0, sscratch, a0，意思是交换两个寄存器的值

但是这好像是 2020 年的版本，新版已经是 csrw sscratch, a0 li a0, TRAPFRAME 了。

然后：

1. 将 kernel 的栈顶指针加载到寄存器 sp 寄存器中
2. 将 kernel 的 hartid （CPU 核编号）加载到 tp 寄存器中
3. 将 usertrap() 函数的地址加载到 t0 寄存器中（打印出来是0x800027a0，属于虚拟地址空间中的 kernel text 区域）
4. 将 kernel page table 的指针加载到 t1 寄存器中
5. 切换 page table，将 kernel page table 的指针加载到 satp 寄存器中
6. 通过 jump 指令跳转到函数：usertrap() ，这是内核的C代码

总结一下做了什么：

1. 保存用户寄存器数据
2. 为内核代码设置好堆栈空间
3. 切换页表

usertrap

细节略了，太多了，根本记不住。

usertrap 负责判断触发 trap 的原因，并执行响应的处理：

• 若是 syscall，则调用对应的系统调用
• 若是设备中断，则跳转到响应的处理代码
• 若是 page fault，则杀死进程
• 最后执行 usertrapret() 函数

一些修改

从后面开始的部分，2025 的版本和 2020 的不一样。

RISC-V assembly

一系列不是很难的题目，就直接把答案放出来了：

Which registers contain arguments to functions? For example, which register holds 13 in main's call to printf?RISC-V 使用 a0～a7 传递前八个函数参数。在 main 对 printf 的调用中，数值 13 位于 a2 寄存器中。Where is the call to function f in the assembly code for main? Where is the call to g? (Hint: the compiler may inline functions.)没有调用 f 和 g 函数，编译器内联了 f(8) + 1 的表达式为 12，表现为汇编代码 li a1,12At what address is the function printf located?根据 30:6c6000ef          jal6f6 <printf> 这一行，位于 6f6What value is in the register ra just after the jalr to printf in main?根据 RISC-V 文档，`jal` 跳转到目标函数时，会把下一条指令的地址保存到 ra，作为目标函数执行完毕之后，跳转到的地址，所以是 0x30 + 4 = 0x34Run the following code.unsigned int i = 0x00646c72;printf("H%x Wo%s", 57616, (char *) &i);      What is the output? Here's an ASCII table that maps bytes to characters.The output depends on that fact that the RISC-V is little-endian. If the RISC-V were instead big-endian what would you set i to in order to yield the same output? Would you need to change 57616 to a different value?输出是 HE110 World$。%x 把 57616 按 16 进制输出则得到 0xe110，然后对于 %s 由于 RISC-V 是小端序，则 i = 0x00646c72，转换成 4 字节无符号整数之后从小到大依次为 r l d 0。如果是大端序则设置 i = 0x726c6400Here's a description of little- and big-endian and a more whimsical description.In the following code, what is going to be printed after 'y='? (note: the answer is not a specific value.) Why does this happen?printf("x=%d y=%d", 3);读到的会是 a2 寄存器里面残存的值，属于 UB 行为。

Backtrace

需要沿着内核栈中的栈指针向上遍历，打印当前函数调用链中的返回地址。

考虑这个核心原理：

当前 fp  fp - 8   → 当前栈帧保存的返回地址  fp - 16  → 调用者的 fp

那么，这样不断循环就可以了。

hint 1：

Add the prototype for your backtrace() to kernel/defs.h so that you can invoke backtrace in sys_pause.

没什么好说的，照做。

hint 2：

The GCC compiler stores the frame pointer of the currently executing function in the register s0. In the section marked by #ifndef ASSEMBLER ... #endif, add the following function to kernel/riscv.h:

static inline uint64r_fp(){  uint64 x;  asm volatile("mv %0, s0" : "=r" (x) );  return x;}

and call this function in backtrace to read the current frame pointer. r_fp() uses in-line assembly to read s0.

这也没啥好说的。照做。

hint 3：

就是所说的那个核心原理。

具体到代码上的处理：

uint64 ra = *(uint64 *)(fp - 8);fp = *(uint64 *)(fp - 16);

hint 4：

Your backtrace() will need a way to recognize that it has seen the last stack frame, and should stop. A useful fact is that the memory allocated for each kernel stack consists of a single page-aligned page, so that all the stack frames for a given stack are on the same page. You can use PGROUNDDOWN(fp) (see kernel/riscv.h) to identify the page that a frame pointer refers to.

意思就是，我们是需要循环的，而循环的终止条件就是 fp 仍然有效，而 fp 的有效性就是看页面是否有效。

首先取得当前 fp 所在页面的起始地址：

uint64 stack_bottom = PGROUNDDOWN(fp);

页面结束地址：

uint64 stack_top = stack_bottom + PGSIZE;

只要 fp 还在这个页面内，就可以继续遍历：

fp >= stack_bottom + 16 && fp < stack_top

别的没什么好说的，照做即可。

voidbacktrace(void){  printf("backtrace:\n");  uint64 fp = r_fp();  // 当前内核栈所在页面的范围  uint64 stack_bottom = PGROUNDDOWN(fp);  uint64 stack_top = stack_bottom + PGSIZE;  while(fp >= stack_bottom + 16 && fp < stack_top){    // 当前函数返回到调用者后的地址    uint64 ra = *(uint64 *)(fp - 8);    printf("%p\n", (void*)ra);    // 切换到调用者的栈帧    fp = *(uint64 *)(fp - 16);  }}

Alarm

按照 hint 照做。

hint 1 2 3 没什么好说的，唯一值得注意的是，sys_sigalarm 和 sys_sigreturn 函数签名我放在了 sysproc.c 中。

hint 4 5，proc.h 这里记录地址，是直接写 uint64 的，后面强转成指针即可。

hint 6 7，本质是一个点，其实只看 hint7 的指示就可以了。

hint 8 9，照着说明去做。

• hint 8 的意思是，判断 alarm 是否有效，应该使用 p->alarm_interval > 0
• hint 9 的意思是，alarm 到期时，执行 p->trapframe->epc = p->alarm_handler; 以改变跳回之后的程序计数器。

hint 10 之后的内容，是这题的重头戏。

hint 11 问，应该保存哪些寄存器？并且提示有很多。答案是应该保存所有的用户寄存器。因为执行 handler 是可能改变很多寄存器的内容的。最简单的方案，是保存整个 trapframe。

因而，hint 12 就是解决这一点的。在 struct proc 中加一个 struct trapframe alarm_trapframe：

• p->trapframe：当前正在使用的用户现场，会随着 handler 和系统调用变化
• p->alarm_trapframe：alarm 发生前原程序现场的固定快照

解决方案，就是：

memmove(&p->alarm_trapframe, p->trapframe, sizeof(struct trapframe));p->trapframe->epc = p->alarm_handler;

hint 13，主要是解决防止 handler 重入的问题。具体而言：handler 运行期间，显然可能重新发生定时器中断，若再次触发 alarm，则原来的 handler 递归进入自己，导致 alarm_trapframe 被执行 handler 过程中的 trapframe 覆盖，sigreturn() 永远无法找到被中断的源程序。

解决方案是加一个 flag int alarm_handling;，在 allocproc 中初始化为 0，只有满足 p->alarm_interval > 0 && !p->alarm_handling 时才能累计触发 alarm，并且触发时置 p->alarm_ticks = 0; 和 p->alarm_handling = 1;。

最后是 hint14，sys_sigreturn() 将备份恢复到当前 trapframe，也就是：

memmove(p->trapframe,        &p->alarm_trapframe,        sizeof(struct trapframe));

但是 a0 特殊，因为 a0 被认为是返回值。而阅读 syscall() 的代码，会发现执行系统调用的方式是：

p->trapframe->a0 = syscalls[num]();

即，必须要保存好原始的 a0 并作为 sigreturn() 的返回值。

uint64sys_sigreturn(void){  struct proc *p = myproc();  uint64 old_a0 = p->alarm_trapframe.a0;  memmove(p->trapframe, &p->alarm_trapframe, sizeof(struct trapframe));  p->alarm_handling = 0;  return old_a0;}

运行 make grade：

找到了两个很好的中文翻译的版本：

• 课程介绍 · 6.S081 All-In-One
• HelloYJohn/xv6-riscv-book-zh-cn: translation of xv6-riscv-book

那么就试着速览一下第三章吧。

• 我发现我还是读不进去书，不如直接开始做 lab 然后学吧。

Inspect a user-process page table

不需要写代码，主要是 inspect 一下。

运行 pgtbltest：

打印出的是此进程的 first 10 and last 10 PTE。

分析一下，首先根据 xv6 book，一个 PTE 的结构如图：

则：

• va：进程看到的虚拟页地址
• pte：完整页表项
• pa：它映射到的物理页地址
• perm：PTE 低 10 位的标志位

因为一页是 4096 Bytes 即 0x1000 Bytes，故可以见到 va 分别为 0x0 0x1000 0x2000...。

逐个解析每个 PTE 的 perm：

再考虑图 3.4：

从低位开始分析 va 0x0、va 0x1000 都是 perm 0x5B = R-XU，即：可读、可执行、用户可访问，不可写。那么显然，是 text 部分。

再分析 va 0x2000，perm 0x17 = R-WU 对应可读、可写、用户可访问，不可执行，对应 data R-WU。

之后分析也同理，对着看就行。而且很显然，最高的两页分别就是 trampoline 和 trapframe。

Speed up system calls

这道题虽然说是 easy，但是我还是有点「面向答案学习」了（指不会做，问 Agent 然后看答案的）。

梳理一下需求：kernel/memlayout.h 里面定义了一个这样的虚拟地址（va）：

#define USYSCALL (TRAPFRAME - PGSIZE)

需求是：在这个页面处定义一个这样的 struct：

struct usyscall {  int pid;  // Process ID};

将其初始化为当前进程的 PID，以此消除了调用 getpid() 系统调用（陷入内核态）的必要，用户态就可直接从内存中读取 pid。

hint 提示我们：

• Choose permission bits that allow userspace to only read the page.选择允许用户空间仅读取该页面的权限位。
• There are a few things that need to be done over the lifecycle of a new page. For inspiration, understand the trapframe handling in kernel/proc.c.在新页面的生命周期中，有几件事情需要处理。作为参考，请理解 kernel/proc.c 中的 trapframe 处理。

简单梳理一下的意思就是，参考图 3.4，我们有一个 trapframe 的 va，现在我们在 trapframe 的正下方，又加了一个 usyscall。对于 usyscall 的实现，可以完全参考在 kernel/proc.c 中对于 trapframe 的处理。

那么，首先需要在 kernel/proc.h ，参考 trapframe 给 struct proc 加一个 struct usyscall *usyscall：

struct trapframe *trapframe; // data page for trampoline.Sstruct usyscall *usyscall;   // USYSCALL page, shared read-only with user

然后，在 kernel/proc.c 中，Ctrl + F 搜索 trapframe，然后依次参考 trapframe 的实现，来仿照着实现 usyscall 的部分。

// static struct proc* allocproc(void) // Allocate a trapframe page.  if((p->trapframe = (struct trapframe *)kalloc()) == 0){    freeproc(p);    release(&p->lock);    return 0;  }  if((p->usyscall = (struct usyscall *)kalloc()) == 0) {    freeproc(p);    release(&p->lock);    return 0;  }  p->usyscall->pid = p->pid;

因为这里实际上是一个每进程且进程创建之后就不再改变的量，所以 pid 的逻辑在这里就已经实现完毕了。

接下来是：这个是纯粹模仿。

static voidfreeproc(struct proc *p){  if(p->trapframe)    kfree((void*)p->trapframe);  p->trapframe = 0;  if(p->usyscall)    kfree((void *)p->usyscall);  p->usyscall = 0;  ...}

这里是一个比较关键的地方：创建页表。

// Create a user page table for a given process, with no user memory,// but with trampoline and trapframe pages.pagetable_tproc_pagetable(struct proc *p){  pagetable_t pagetable;  // An empty page table.  pagetable = uvmcreate();  if(pagetable == 0)    return 0;  // map the trampoline code (for system call return)  // at the highest user virtual address.  // only the supervisor uses it, on the way  // to/from user space, so not PTE_U.  if(mappages(pagetable, TRAMPOLINE, PGSIZE,              (uint64)trampoline, PTE_R | PTE_X) < 0){    uvmfree(pagetable, 0);    return 0;  }  // map the trapframe page just below the trampoline page, for  // trampoline.S.  if(mappages(pagetable, TRAPFRAME, PGSIZE,              (uint64)(p->trapframe), PTE_R | PTE_W) < 0){    uvmunmap(pagetable, TRAMPOLINE, 1, 0);    uvmfree(pagetable, 0);    return 0;  }  if(mappages(pagetable, USYSCALL, PGSIZE,              (uint64)(p->usyscall), PTE_R | PTE_U) < 0){    uvmunmap(pagetable, TRAPFRAME, 1, 0);    uvmunmap(pagetable, TRAMPOLINE, 1, 0); // !!!    uvmfree(pagetable, 0);    return 0;  }  return pagetable;}

mappages() 是建立 va 到 实际物理地址的映射的，顺便规定好 perm，这里按照原文的说法，允许用户态读。

重点是这个清理步骤：

uvmunmap(pagetable, TRAPFRAME, 1, 0);uvmunmap(pagetable, TRAMPOLINE, 1, 0); // !!!uvmfree(pagetable, 0);

实际上的意思是 (summarized by LLM)：

之后，检查到 kfork 中对于 trapframe 的处理：

// copy saved user registers.*(np->trapframe) = *(p->trapframe);// Cause fork to return 0 in the child.np->trapframe->a0 = 0;

我们容易注意到，事实上 trapframe 的逻辑，是在这里实现的（继承父进程的）。但是，对于 usyscall ，因为 PID 进程创建之后即保持不变，所以其实不需要管这个。

至此，本题实现完成。

Print a page table

虽然说是 easy，但是我一边拷打 AI 一边自己想，写了差不多有 5 个多小时...

大概归纳一下吧，首先，我发现我对多级页表不熟，然后简单手写整理了一下：

hint 里面说：参考 freewalk 函数：

// Recursively free page-table pages.// All leaf mappings must already have been removed.voidfreewalk(pagetable_t pagetable){  // there are 2^9 = 512 PTEs in a page table.  for(int i = 0; i < 512; i++){    pte_t pte = pagetable[i];    if((pte & PTE_V) && (pte & (PTE_R|PTE_W|PTE_X)) == 0){      // this PTE points to a lower-level page table.      uint64 child = PTE2PA(pte);      freewalk((pagetable_t)child);      pagetable[i] = 0;    } else if(pte & PTE_V){      // backtrace();      panic("freewalk: leaf");    }  }  kfree((void*)pagetable);}

大致模仿其框架就可以实现了。

有一个疑惑点：为什么判定一个 PTE 是一个指向下一层page table的 PTE 的条件是：

// 此条件等于该pte不是终末层, 而是指向下一层(pte & (PTE_R|PTE_W|PTE_X)) == 0

其实是 RISC-V 的规定，指向下一层页表的 PTE（非叶子 PTE），其 R、W、X 位必须全为 0。只有指向最终数据页的 PTE（叶子 PTE），才允许设置 R/W/X。

分析源码也可得到印证：

# kernel/vm.c mappages()if(*pte & PTE_V)  panic("mappages: remap");*pte = PA2PTE(pa) | perm | PTE_V;

这里传入的 perm，保证了一定包含 R W X 其一，否则 panic。

然后开始实现 vmprint，因为参数锁死了，所以需要设置一个辅助函数来实现递归遍历：

voidvmprint_recur(pagetable_t pagetable, int level, uint64 va){  for (int i = 0; i < 512; ++i) {    pte_t pte = pagetable[i];    if (pte & PTE_V) { // is a valid PTE      // 这里记得强转 i      uint64 newva = va | ((uint64)i << PXSHIFT(level));      for (int j = 0; j <= 2 - level; j++) {        printf(" ..");      }      printf("%p: pte %p pa %p\n", (void *)newva, (void *)pte, (void *)PTE2PA(pte));      if ((pte & (PTE_R|PTE_W|PTE_X)) == 0) {        vmprint_recur((pagetable_t)PTE2PA(pte), level - 1, newva);      }    }  }}voidvmprint(pagetable_t pagetable){  printf("page table %p\n", pagetable);  // ！！从 2 开始 而不是从 1 开始！！  vmprint_recur(pagetable, 2, 0);}

别的都还好，主要是这个计算 newva，着重说明一下：

pagetable[i] 里的 i 和 VA 是线性对应的，我开始以为，像 for(int i=0;i<512;i++) pagetable[i] 这样的遍历得到的是毫无逻辑杂乱无章的，但是实际上，考虑多级页表的原理，这个 i 就是对应虚拟地址 va 的第 i 段。更具体地说：

调用递归函数的时候，传入的参数也是个问题；以及最重要的，如何计算虚拟地址 va？这两个问题放在一起说明。

首先，务必要明晰这个模型：

[ VPN2 ][ VPN1 ][ VPN0 ][ offset ]                              ↑ 12 位

而且通过阅读 walk 函数，我们也容易注意到，level 的取值只有 0 1 2，而且是越开始越高，所以，开始传入的 level 肯定是2。

#define PXMASK          0x1FF // 低9位是1#define PXSHIFT(level)  (PGSHIFT+(9*(level)))#define PX(level, va) ((((uint64) (va)) >> PXSHIFT(level)) & PXMASK)

现在，再考虑 newva 是怎么计算出来的（uint64 newva = va | ((uint64)i << PXSHIFT(*level*));），就很清晰了，就是在上一次的基础上，累计这一层的偏移量。

总之，感觉我对概念的理解实在是太差了，有点难办呢。花了 5 个小时去解决这么一个 easy 的题目确实有点挫败感了，不过也没办法，继续写下去吧。

Use superpages

看到这个 Hard 的题目，有点慌，所以去网上搜了搜这些知识的解析，结果意外发现一些不错的资料：

• MIT6.s081/6.828 lectrue04：page tables 以及 Lab3 心得 - 逆风的大船的文章 - 知乎 https://zhuanlan.zhihu.com/p/651171058
  • 这个博主的手写笔记极为详细啊，很有用
• https://mit-public-courses-cn-translatio.gitbook.io/mit6-s081
  • 每节课的「文字版录播」，我觉得比 xv6 book 好多了，而且同学们问的问题也不错。

简单摘录一些：

• kvminithart 函数，很重要：

  这个函数首先设置了SATP寄存器，kernel_pagetable变量来自于kvminit第一行。所以这里实际上是内核告诉MMU来使用刚刚设置好的page table。当这里这条指令执行之后，下一个指令的地址会发生什么？

  在这条指令之前，还不存在可用的page table，所以也就不存在地址翻译。执行完这条指令之后，程序计数器（Program Counter）增加了4。而之后的下一条指令被执行时，程序计数器会被内存中的page table翻译。

  所以这条指令的执行时刻是一个非常重要的时刻。因为整个地址翻译从这条指令之后开始生效，之后的每一个使用的内存地址都可能对应到与之不同的物理内存地址。因为在这条指令之前，我们使用的都是物理内存地址，这条指令之后page table开始生效，所有的内存地址都变成了另一个含义，也就是虚拟内存地址。

• 为什么通过3级page table会比一个超大的page table更好呢？

  Frans教授：这是个好问题，这的原因是，3级page table中，大量的PTE都可以不存储。比如，对于最高级的page table里面，如果一个PTE为空，那么你就完全不用创建它对应的中间级和最底层page table，以及里面的PTE。所以，这就是像是在整个虚拟地址空间中的一大段地址完全不需要有映射一样。

• proc_mapstacks()函数比较有趣，参考 MIT6.s081/6.828 lectrue4：page tables 以及 Lab3 心得 - byFMH - 博客园 的部分阅读

• pageguard 的作用是什么？

  保护页是一页故意禁止访问的虚拟内存，放在栈旁边，用来检测栈溢出。

  例如内核栈：

  kernel stackguard page    ← 不映射kernel stackguard page

  如果内核栈不断向下增长，越过边界访问保护页，就会触发 page fault，最终使内核 panic。

  这样比栈悄悄覆盖其他内核数据要好：尽早暴露错误，而不是继续带着损坏的数据运行。

  xv6 中有两种：

  • 内核栈保护页：PTE 无效，内核访问也会 fault。
  • 用户栈保护页：清除 PTE_U，用户态不能访问，栈溢出时进程会 fault。

• 理解这一节学生问的问题很重要：4.5 Kernel Page Table | MIT6.S081

  内核页表也存在对用户进程的映射，而且对于内核而言，va == pa，是相同的。

总之，把这些内容读完了之后（虽然还是有点混乱），再开始实现这个 Lab：

目的是实现 superpage：

• RISC-V 默认页面大小为 4KB
• 这里需要实现大小为 2MB 的页

阅读 hint：

阅读 user/pgtbltest.c 中的 superpg_fork 和 superpg_free 。

自己看有点费劲，让 Agent 代劳：

再看下一个 hint：

一个好的起点是 kernel/sysproc.c 中的 sys_sbrk ，它由 sbrk 系统调用调用。跟踪代码路径到 growproc 函数，该函数为 sbrk 立即分配内存。

// kernel/sysproc.cuint64sys_sbrk(void){  uint64 addr;  int t;  int n;  argint(0, &n); // 第 0 个参数：要增长/缩减的字节数  argint(1, &t); // 第 1 个参数：分配策略 (SBRK_EAGER=1 或 SBRK_LAZY=2)  addr = myproc()->sz; // 保存旧堆顶地址，作为返回值  if(t == SBRK_EAGER || n < 0) {    if(growproc(n) < 0) {      return -1;    }  } else {    // Lazily allocate memory for this process: increase its memory    // size but don't allocate memory. If the processes uses the    // memory, vmfault() will allocate it.    if(addr + n < addr)      return -1;    myproc()->sz += n;  }  return addr;}

这里可能会误以为 sbrk() 有两个参数，但实际上是用户态有两个调用入口：

// user/ulib.cchar* sbrk(int n)     { return sys_sbrk(n, SBRK_EAGER); }  // 立即分配char* sbrklazy(int n)  { return sys_sbrk(n, SBRK_LAZY);  }  // 惰性分配

立即分配：调用 growproc(n) 立即调配物理内存：

// kernel/proc.c// Shrink user memory by n bytes.// Return 0 on success, -1 on failure.intgrowproc(int n){  uint64 sz;  struct proc *p = myproc();  sz = p->sz;  if(n > 0){    if((sz = uvmalloc(p->pagetable, sz, sz + n, PTE_W)) == 0) {      return -1;    }  } else if(n < 0){    sz = uvmdealloc(p->pagetable, sz, sz + n);  }  p->sz = sz;  return 0;}

• n > 0 则分配物理页+建立页表的映射（在 uvmalloc 函数里面建立）
• n < 0 则立即释放物理页

这里注意，n < 0 时则无视懒分配策略。

懒分配：

只改 p->sz，不分配物理内存，实际分配推迟到 page fault 发生时："vmfault() will allocate it."：

// kernel/vm.c// allocate and map user memory if process is referencing a page// that was lazily allocated in sys_sbrk().// returns 0 if va is invalid or already mapped, or if// out of physical memory, and physical address if successful.uint64vmfault(pagetable_t pagetable, uint64 va, int read){  uint64 mem;  struct proc *p = myproc();    if (va >= p->sz)    return 0;  va = PGROUNDDOWN(va);  if(ismapped(pagetable, va)) {    return 0;  }  mem = (uint64) kalloc();  if(mem == 0)    return 0;  memset((void *) mem, 0, PGSIZE);  if (mappages(p->pagetable, va, PGSIZE, mem, PTE_W|PTE_U|PTE_R) != 0) {    kfree((void *)mem);    return 0;  }  return mem;}

核心就是：在 va < p->sz （合法但未分配）时，分配内存。

0x0├── text (代码)├── data (数据)├── guard page (保护页)├── heap (堆) ← sbrk 管理，向上增长│   ...│   └── 堆顶 = p->sz││   (未分配)│└── MAXVA    └── trampoline / trapframe

intismapped(pagetable_t pagetable, uint64 va) {  pte_t *pte = walk(pagetable, va, 0);  if (pte == 0) {    return 0;  }  if (*pte & PTE_V){    return 1;  }  return 0;}

再看下一个 hint：

你的内核需要能够分配和释放 2MB 的区域。修改 kalloc.c 以预留一些两兆字节的物理内存区域，并创建 superalloc() 和 superfree() 函数。你只需要少量两兆字节的内存块。

什么叫「预留一些内存区域」？我们可以阅读源码得到答案。

首先，看到 main.c：

// start() jumps here in supervisor mode on all CPUs.voidmain(){  if(cpuid() == 0){    consoleinit();    printfinit();    printf("\n");    printf("xv6 kernel is booting\n");    printf("\n");    kinit();         // physical page allocator    kvminit();       // create kernel page table    kvminithart();   // turn on paging    procinit();      // process table    trapinit();      // trap vectors    trapinithart();  // install kernel trap vector    plicinit();      // set up interrupt controller    plicinithart();  // ask PLIC for device interrupts    binit();         // buffer cache    iinit();         // inode table    fileinit();      // file table    virtio_disk_init(); // emulated hard disk    userinit();      // first user process    __sync_synchronize();    started = 1;  } else {    while(started == 0)      ;    __sync_synchronize();    printf("hart %d starting\n", cpuid());    kvminithart();    // turn on paging    trapinithart();   // install kernel trap vector    plicinithart();   // ask PLIC for device interrupts  }  scheduler();        }

注意到，这里 kinit(); // physical page allocator ，一个定义在 kalloc.c 里面的函数，起到了分配物理页的作用，其实也就是分配了空闲列表。

再去看到 kalloc.c：

extern char end[]; // first address after kernel.                   // defined by kernel.ld.struct run {  struct run *next;};struct {  struct spinlock lock;  struct run *freelist;} kmem;voidkinit(){  initlock(&kmem.lock, "kmem");  freerange(end, (void*)PHYSTOP);}

kmem 就是一个带锁的空闲列表，看到 kinit，暂时忽略锁的部分（后续章节再涉及），发现调用了 freerange 函数，那么再看：

voidfreerange(void *pa_start, void *pa_end){  char *p;  p = (char*)PGROUNDUP((uint64)pa_start);  for(; p + PGSIZE <= (char*)pa_end; p += PGSIZE)    kfree(p);}

这里 PGROUNDUP 宏的作用是向上匀，保证开始的地址是 PGSIZE 的整数倍。

可以发现，是从新的开始处开始，直到 pa_end，一页一页地调用 kfree(p) 来释放。

char*   p + 1  →  地址 + 1 字节   ✓ 精细到每个字节int*    p + 1  →  地址 + 4 字节   ✗ 太粗糙了uint64* p + 1  →  地址 + 8 字节   ✗ 太粗糙了

那么我们再看 kfree()：

// Free the page of physical memory pointed at by pa,// which normally should have been returned by a// call to kalloc().  (The exception is when// initializing the allocator; see kinit above.)voidkfree(void *pa){  struct run *r;  if(((uint64)pa % PGSIZE) != 0 || (char*)pa < end || (uint64)pa >= PHYSTOP)    panic("kfree");  // Fill with junk to catch dangling refs.  memset(pa, 1, PGSIZE);  r = (struct run*)pa;  acquire(&kmem.lock);  r->next = kmem.freelist;  kmem.freelist = r;  release(&kmem.lock);}

首先是一个合理性校验，虽然读 OSTEP 的时候说，这一块主要是硬件 MMU 实现的，不知道为什么这里在 OS 代码层面实现了。

然后是把这一块内存填满垃圾。

最后，这一块就是保证原本的 r->next 不丢失，从而释放掉原本的 pa 处的页。

干脆读完，看 kalloc 函数：

// Allocate one 4096-byte page of physical memory.// Returns a pointer that the kernel can use.// Returns 0 if the memory cannot be allocated.void *kalloc(void){  struct run *r;  acquire(&kmem.lock);  r = kmem.freelist;  if(r)    kmem.freelist = r->next;  release(&kmem.lock);  if(r)    memset((char*)r, 5, PGSIZE); // fill with junk  return (void*)r;}

别的没什么，这里我开始有个疑惑：这里明明是分配的栈上的指针 r，函数结束之后不应该就消失了吗？

但是实际上，r 存的是地址，不是内存本身。这个指针变量确实在栈上，函数返回后它作为局部变量就销毁了。

总之，读完这部分代码之后，再去理解「预留」：实际上就是 freerange 这一块：

for(; p + PGSIZE <= (char*)pa_end; p += PGSIZE)

每次只按照 PGSIZE 为单位进行分配，那当然就没有 superpage 的份了。

那么我们动手开始实现：

仿照 4KB 页的 freelist 照抄一个：

struct {  struct spinlock lock;  struct run *freelist;} ksupermem;

顺便，在 kernel/riscv.h 里面定义一下 hint 中所说的 a handful of 具体是多少，考虑到 xv6 的内存没多大，姑且设置成 8 个：

#define SUPERPGAMOUNT 16

然后，逻辑基本仿照即可。

这里留一个疑问，设置 cnt_superpage 是在 superfree 还是 superalloc？之后解决。

再看下两个 hint（一块实现）：

支持大页的进程在 fork 时需分配大页，在退出时释放大页；你需要修改 uvmcopy() 和 uvmunmap() 的相关逻辑。

当 sbrk 部分释放一个超级页（例如，释放一个超级页的最后 4096 字节）时，你需要将该超级页“降级”为普通页。

读一下代码：

voiduvmunmap(pagetable_t pagetable, uint64 va, uint64 npages, int do_free){  uint64 a;  pte_t *pte;  int sz = PGSIZE;                    // 每次跳 4KB（后面 superpage 需要改这里）  if((va % PGSIZE) != 0)    panic("uvmunmap: not aligned");  for(a = va; a < va + npages*PGSIZE; a += sz){    if((pte = walk(pagetable, a, 0)) == 0)   // ① 找 PTE      continue;                              //    没找到 → 跳过（允许不存在）    if((*pte & PTE_V) == 0)                  // ② V 位没置      continue;                              //    已失效 → 跳过    sz = PGSIZE;                             // ③ 重置 sz（后面 superpage 需要改这里）    if(PTE_FLAGS(*pte) == PTE_V)      panic("uvmunmap: not a leaf");         // ④ 必须是叶节点    if(do_free){      uint64 pa = PTE2PA(*pte);      kfree((void*)pa);                      // ⑤ 释放物理页    }    *pte = 0;                                // ⑥ 清空 PTE  }}

// 场景：创建页表，先 map 了 trampoline，然后 map trapframe 失败了if(mappages(pagetable, TRAPFRAME, ...) < 0){    uvmunmap(pagetable, TRAMPOLINE, 1, 0);   // ← do_free=0    uvmfree(pagetable, 0);    return 0;}

intuvmcopy(pagetable_t old, pagetable_t new, uint64 sz){  pte_t *pte;  uint64 pa, i;  uint flags;  char *mem;  int szinc = PGSIZE;              // 步长（后面 superpage 需要改这里）  for(i = 0; i < sz; i += szinc){    if((pte = walk(old, i, 0)) == 0)    // ① 在父进程页表中找 i 对应的 PTE      continue;                          //    没有 → 跳过    if((*pte & PTE_V) == 0)             // ② PTE 无效      continue;                          //    跳过    szinc = PGSIZE;                      // ③ 重置步长    pa = PTE2PA(*pte);                   // ④ 提取物理地址    flags = PTE_FLAGS(*pte);             // ⑤ 提取权限位    if((mem = kalloc()) == 0)            // ⑥ 分配新物理页      goto err;    memmove(mem, (char*)pa, PGSIZE);     // ⑦ 把父进程物理页内容拷贝过来    if(mappages(new, i, PGSIZE, (uint64)mem, flags) != 0){  // ⑧ 映射到子进程页表      kfree(mem);      goto err;    }  }  return 0; err:  uvmunmap(new, 0, i / PGSIZE, 1);      // 失败回滚：释放已分配的所有页  return -1;}

现在两个函数都硬编码了 4KB 粒度（szinc = PGSIZE，sz = PGSIZE）。支持 superpage 后，walk 可能返回的是一个 L2 级别的 leaf PTE（代表 2MB 大页），所以才需要修改。

但是，这里有个问题：如何判断一个 PTE 是不是 superpage？LLM 的给的说法是，如果在 L1 层就发现这个 PTE 是 leaf page（L2 -> L1 -> L0），那么就是 superpage。

// return the page size of a specific pteintpagesize(pagetable_t pagetable, uint64 va){  pte_t *pte;  pte = &pagetable[PX(2, va)];  if ((*pte & PTE_V) == 0) {    return PGSIZE;  }  pagetable_t l1 = (pagetable_t)PTE2PA(*pte);  pte = &l1[PX(1, va)];  if ((*pte & PTE_V) && PTE_LEAF(*pte)) {    return SUPERPGSIZE;  }  return PGSIZE;}

然后，接下来这一部分写了我快两天...

先分析一下 uvmunmap，作用是解除 [va, va + npages*PGSIZE) 的映射。这个 PTE 可能是 4KB 页也可能是 2MB superpage。

对于 4KB 页正常处理，对于 superpage：

• 首先判断其是否是 superpage，方法就是 if(pagesize(*pagetable*, a) == SUPERPGSIZE)

• 找到一些关键的参数：

  uint64 sp_start = ((a % SUPERPGSIZE) == 0) ? a : SUPERPGROUNDDOWN(a); // 这里注意一下，这个宏有问题uint64 sp_end = sp_start + SUPERPGSIZE;uint64 unmap_end = va + npages * PGSIZE;

• 然后，分三种情况：

  • 整块释放：a == sp_start && sp_end <= unmap_end，则就直接调用 superfree 即可

  • 部分释放：这个地方就需要考虑把当前 superpage 给降级成一个或多个 4KB 页，这里实现一个函数 split_superpage：

    代码C · 40 行

    // Split a 2MB superpage into 512 individual 4KB pages.// Pages within [unmap_start, unmap_end) are left unmapped (L0[j]=0).// All other pages within the superpage are allocated new 4KB pages// with data copied from the original 2MB block.// The original 2MB physical block is freed.static voidsplit_superpage(pagetable_t pagetable, uint64 sp_start,                uint64 unmap_start, uint64 unmap_end){  if (pagesize(pagetable, sp_start) != SUPERPGSIZE) {    panic("split_sp: not superpage");  }  uint64 sp_end = sp_start + SUPERPGSIZE;  unmap_end = unmap_end < sp_end ? unmap_end : sp_end;  pte_t *l2_pte = &pagetable[PX(2, sp_start)];  pagetable_t l1 = (pagetable_t)PTE2PA(*l2_pte);  pte_t *sp_pte = &l1[PX(1, sp_start)];  uint64 sp_pa = PTE2PA(*sp_pte);  int flags = PTE_FLAGS(*sp_pte);  pagetable_t l0 = (pagetable_t)kalloc();  if (l0 == 0) {    panic("split_sp: kalloc l0");  }  memset((void*)l0, 0, PGSIZE);  for (int i = 0; i < 512; ++i) {    uint64 va = sp_start + i * PGSIZE;    if (va >= unmap_start && va < unmap_end) {      continue;    }    uint64 new_page = (uint64) kalloc();    if (new_page == 0) {      panic("split_sp: kalloc page");    }    memmove((void*)new_page, (void*)(sp_pa + i * PGSIZE), PGSIZE);    l0[i] = PA2PTE(new_page) | flags | PTE_V;  }  *sp_pte = PA2PTE(l0) | PTE_V;  superfree((void*)sp_pa);}

    大致的思路就是原本是 L2 指向的 L1 后面直接指向一个 superpage，现在需要把这个 superpage 拆散成若干普通页，这些普通页记录在一个 L0 页表里面，最后把原本 L1 指向的 PTE （就是 superpage 的物理地址）直接修改为重新分配到的 L0 的位置

然后是修改 uvmcopy：

原本的函数只是用 mappages 来建立虚拟地址到物理地址的映射，且只使用 4KB 页。为了支持 superpage，在 uvmcopy 中，如果原本的进程处的页是一个 superpage，子进程这里也应该是一个 superpage，所以我们必须要先创建一个 map_superpage：

关于 map_superpage，无非就是 split_superpage 的逆操作：在子进程页表里新建一个 L1 叶子 PTE。

• 首先取到 L1 页表，如果不存在自行创建（为什么 mappages 不需要「不存在则自行创建」这一步？因为在 walk 中解决了）
• 然后，在 L1 页表的 PTE，原本该指向 L0 页表的 pte 的位置处，改为 PA2PTE(*pa*) | *perm* | PTE_V
• 为什么这是一个 superpage？因为通过设置 flags，在 L1 层的 leaf page 当然就是一个 superpage。
• 实现完这个之后，修改 uvmcopy 其实就照抄 4KB 的逻辑差不多了。

// Create a 2MB superpage mapping at L1.// va and pa must be 2MB-aligned. Returns 0 on success, -1 on failure.static intmap_superpage(pagetable_t pagetable, uint64 va, uint64 pa, int perm){  // Ensure the L1 page table exists (L2 already points to it)  pte_t *l2 = &pagetable[PX(2, va)];  pagetable_t l1;  if(*l2 & PTE_V){    l1 = (pagetable_t)PTE2PA(*l2);  } else {    if((l1 = (pagetable_t)kalloc()) == 0)      return -1;    memset(l1, 0, PGSIZE);    *l2 = PA2PTE(l1) | PTE_V;  }  pte_t *l1_pte = &l1[PX(1, va)];  if(*l1_pte & PTE_V)    return -1;  // already mapped  *l1_pte = PA2PTE(pa) | perm | PTE_V;  // R/W/X bits → hardware sees a leaf  return 0;}

最后，还需要改 uvmalloc 函数，因为目前还没有处理关于超级页的分配的逻辑。

这里也不麻烦，如果剩余的范围有 2MB 并且地址是对齐的，就尝试调用 superalloc 分配一个，这里的逻辑和下面调用 kalloc 以分配正常页的逻辑没什么区别。

至此就完成了，测试的时候，先 make qemu，再输入 pgtbltest。

操作系统主要解决三个要求：

• multiplexing：多个程序共享 CPU、内存等资源；
• isolation：一个程序不能破坏内核或其他程序；
• interaction：程序仍然需要通过管道等机制进行受控通信。

因此出现了这些抽象：

RISC-V 的特权级：

• machine mode：启动阶段使用，权限最高；
• supervisor mode：xv6 内核运行于此；
• user mode：普通应用运行于此。

需要内核服务时，在 user mode 执行 ecall 陷入内核态。

宏内核：

• 文件系统、进程管理、内存管理、驱动等都运行在内核态。
• 优点是调用直接、模块协作方便、性能较好；缺点是内核庞大，任何严重 bug 都可能让整个系统崩溃。
• xv6 是宏内核，所有核心模块都在 kernel/ 中直接互相调用。

微内核：

• 内核只保留调度、地址空间、IPC 等基本机制；文件系统等作为用户态服务器运行，通过消息通信
• 优点是内核更小、更容易隔离和验证；缺点是跨进程通信会增加实现和性能开销。

xv6 源码的组织：

xv6 中的进程：

每个进程在内核中有一个 struct proc，其中重要内容包括：

• pagetable：用户地址空间；
• kstack：进入内核后使用的内核栈；
• trapframe：保存用户寄存器；
• context：内核线程上下文；
• state：运行、可运行、睡眠等状态。

进程有两套栈：

• 用户态运行：使用 user stack
• 进入内核：使用该进程自己的 kernel stack

用户栈即使损坏，也不应该影响内核栈。xv6 中一个进程只有一个线程，现代系统通常允许一个进程拥有多个线程。

调用一个系统调用的过程的例子：

调用 write(2, "$", 2);：

用户 C 代码调用 write()        ↓user/usys.S 中的 write 标签 （这一步是通过链接实现的）        ↓a7 = SYS_write        ↓ecall        ↓uservec → usertrap → syscall()        ↓syscalls[SYS_write]        ↓sys_write()        ↓返回值写入 trapframe->a0        ↓恢复用户寄存器，回到 write() 后面

RISC-V 调用约定中：

• a0、a1、a2……保存函数参数；
• a7 保存系统调用编号；
• a0 同时用来保存返回值。

系统调用中汇编代码的联系方式：

user.h 中的声明 + usys.S 中的汇编包装函数 + 链接器将两者对应起来

xv6 的启动

这一块是我写 lab 3 的时候感觉没弄懂的，所以回来补一下。

参考的资料：

• 3.9 XV6 启动过程 | MIT6.S081
• MIT6.s081/6.828 lectrue02：OS design 以及 Lab2 心得 - 逆风的大船的文章 - 知乎
• 重读 xv6（I） | Anri’s blog

QEMU

首先我们需要理解什么是 QEMU。

应该把 QEMU 想象为一个真正的，基于 RISC-V 的计算机对待。

但是，直观上来看，QEMU 是一个开源 C 语言程序，内部的核心就是一个 while(1) 循环，执行：

• 读取 RISC-V 指令
• 解析，找到对应的 op code
• 在软件中执行相应的指令。

xv6 启动流程

RISC-V 有三种 CPU 执行指令的模式：机器模式、内核模式、用户模式。

启动流程：

1. 机器启动，将 kernel 加载到内存
2. 运行 entry.S，为每个 CPU 设置运行栈，此时为 machine mode
3. 运行 start，进行一些初始配置，切换为 kernel mode
4. 运行 main，初始化各个模块，创建首个进程，切换为 user mode
5. 运行 init，设置标准 I/O，启动 shell，开始提供服务

start ：

• 时钟中断，用于虚拟化 CPU，切换进程
• 页表映射，用于虚拟化内存地址

main ：

• 内存池、分页，用于分配用户空间，虚拟化内存
• trap 中断，用于响应异常，实现系统调用
• 进程管理，用于分配资源，管理进程
• 文件系统，用于控制文件读写
• PLIC、设备驱动、磁盘

实际远比这些复杂，之后会单开一个 blog 文章解析一下此过程，TODO。

• 找到一个很不错的 b 站视频：【04(1)-xv6操作系统-系统启动-1（bootblock）】 ，之后评鉴一下。

Using gdb

一系列练习使用 gdb 的回答练习。

这一段说实话有点无聊，因为我之前没有很好的，关于使用 gdb debug 的经历。所以我大部分是让 LLM 指导我做的。

答题：

Looking at the backtrace output, which function called syscall?usertrap() at kernel/trap.c:68What is the value of p->trapframe->a7 and what does that value represent? (Hint: look at user/init.c, the first user program xv6 starts, and its compiled assembly user/init.asm.)$4 = 0xf, 当前进程 p 进入内核时，保存下来的用户态寄存器 a7 的值。0xf = 15，而 SYS_OPEN = 15，所以代表 open 系统调用。What was the previous mode that the CPU was in?用户态Write down the assembly instruction the kernel is panicing at. Which register corresponds to the variable num?得到：scause=0xd sepc=0x80001cf8 stval=0x0panic: kerneltrap再得到：4410:    80001cf8:      00002683                lw      a3,0(zero) # 0 <_entry-0x80000000>a3 对应 numWhy does the kernel crash? Hint: look at figure 3-3 in the text; is address 0 mapped in the kernel address space? Is that confirmed by the value in scause above?代码 *(int *)0 要求 CPU 从虚拟地址 0 读取数据，但内核页表没有映射地址 0，于是发生 page fault。What is the name of the process that was running when the kernel paniced? What is its process id (pid)?(gdb)p p->name$1 "init",\000'<repeats 11 times>(gdb)p/d p->pid$2=1

一个疑惑：

Sandbox a Command

这感觉主要就是建立认知和 insight，但是感觉文档给的引导不足，或者是我太菜了（大概是这样。）

• 二遍：其实 xv6 book 里面写的很清楚，但是我读书不仔细。不过也无所谓，写完也清楚机制了。

一个问题：

照着 hint 一步一步实现，然后有一步需要注意：

if (p->syscall_mask & (1 << num)) {  p->trapframe->a0 = -1;} else {  p->trapframe->a0 = syscalls[num]();}

我开始写的是：

if (p->syscall_mask & (1 << num)) {  prinf(...) // 一段错误日志}

系统调用返回用户态时，用户程序会把 a0 当作返回值。此时 a0 原本保存的通常还是系统调用的第一个参数。如果只打印日志，不修改 a0，返回用户态后，open() 可能把 "README" 的地址当作返回值，而不是得到失败的 -1。

总结一下，跟着 hint 一步一步走，我们究竟实现了什么：

第一步

Add $U/_sandbox to UPROGS in Makefile将 $U/_sandbox 添加到 Makefile 中的 UPROGS 中

没什么好说的，这相当于告知哪些用户程序需要被编译，并放进 xv6 的文件系统。

第二步

在 user/user.h 里提供一个用户的接口，只specify函数原型签名即可：

int interpose(int, const char *);

在 kernel/syscall.h 里面添加系统调用号：

# kernel/syscall.h#define SYS_interpose 22

然后，修改 user/usys.pl：

这里的 pl 后缀是 Perl 脚本，类似于这样：

# user/usys.pl...省略...entry("getpid");entry("sbrk");entry("pause");entry("uptime");entry("interpose");

这究竟有什么用呢？make 会生成如这样的 stub：

.global interposeinterpose:  li a7, SYS_interpose  ecall  ret

sbrk:  li a7, SYS_sbrk  ecall  ret

把系统调用编号 SYS_sbrk 放进 a7执行 ecall 进入内核内核处理完后返回

sys_sbrk()

growproc()uvmalloc()kalloc()

用户程序调用 sbrk()        ↓用户态 syscall stub        ↓ecall        ↓内核 syscall()        ↓sys_sbrk()

stub：负责转交请求implementation：负责真正完成工作

user/user.h 中的声明    告诉 C 编译器函数怎么调用user/usys.pl 生成的 stub    把调用转换成 ecallkernel/sys_xxx()    真正接收和处理系统调用

第三步

Add a sys_interpose() function in kernel/sysproc.c that implements the new system call by recording the mask argument in a new field in the proc structure (see kernel/proc.h). The functions to retrieve system call arguments from user space are in kernel/syscall.c, and you can see examples of their use in kernel/sysproc.c. Add your new sys_interpose to the syscalls array in kernel/syscall.c.在 kernel/sysproc.c 中添加一个 sys_interpose() 函数，通过将掩码参数记录在 proc 结构（见 kernel/proc.h ）的新字段中，来实现新的系统调用。从用户空间检索系统调用参数的函数位于 kernel/syscall.c 中，你可以在 kernel/sysproc.c 中看到它们的使用示例。将新的 sys_interpose 添加到 kernel/syscall.c 的 syscalls 数组中。

修改 struct proc：

容易见到这个限制的掩码是一个每进程变量，因此要放在 struct proc 里面。

关于这个结构体是什么，回去看 read xv6 book 部分的「xv6 中的进程」。

于是，进入 kernel/proc.h，加入一个 int syscall_mask 字段。

修改 kernel/syscall.c：

首先在其他系统调用的声明附近加上

extern uint64 sys_interpose(void);

然后找到系统调用表，把 sys_interpose 加入：

// An array mapping syscall numbers from syscall.h// to the function that handles the system call.static uint64 (*syscalls[])(void) = {// ... 省略[SYS_close]   sys_close,[SYS_interpose] sys_interpose,};

之后写 sys_call() 函数的时候，会理解这一点。

然后，实现 sys_interpose：

在 kernel/sysproc.c 里面：

uint64sys_interpose(void){  int mask; // // 在内核栈中准备一个变量  argint(0, &mask); // // 取得用户传入的第 0 个参数，存入 mask  myproc()->syscall_mask = mask; // 把掩码保存到当前进程  return 0;}

可能会疑惑，这看着根本没实现任何东西啊？我的理解是，这里只是起到了一个从用户态传参的作用。

第四步

Modify kfork() (see kernel/proc.c) to copy the mask from the parent to the child process.修改 kfork() （见 kernel/proc.c ），将掩码从父进程复制到子进程。

因为子进程的掩码要继承父进程的。

也很简单，在 kfork() 函数里面加入一个这个语句：

np->syscall_mask = p->syscall_mask;

即可。

第五步

Modify the syscall() function in kernel/syscall.c to check if the system call must be rejected.修改 kernel/syscall.c 中的 syscall() 函数，以检查系统调用是否必须被拒绝。

if(num > 0 && num < NELEM(syscalls) && syscalls[num]) {  if(p->syscall_mask & (1 << num)) {    p->trapframe->a0 = -1;  } else {    p->trapframe->a0 = syscalls[num]();  }} else {  printk("%d %s: unknown sys call %d\n",         p->pid, p->name, num);  p->trapframe->a0 = -1;}

这里才是真正实现 interpose 逻辑的地方。

其实我觉得这样的耦合，怪怪的。因为实现某个机制，居然要把它实现在一个调用 syscall 的通用函数里面耦合起来，感觉不太好，不过也没想到什么更好的实现机制了。

从头到尾捋一遍思路

用户态调用 interpose：

• 用户调用我们实现的系统调用接口 int interpose(int, const char*)
• 这个接口的实现由 perl 脚本生成的汇编语言实现，把 SYS_interpose 的代号放入 a7 寄存器，由 ecall 硬件支持用户态转入内核态，用户态的函数栈帧存入 myproc()->trapframe（xv6 book 4.2 中详细讲解了）
• 控制转入 xv6 提供的通用接口 void syscall(void)，通过int num; num = p->trapframe->a7; 来获得需要调用的 syscall，然后从 uint64 (*syscalls[])(void) 这个函数指针的数组跳转到具体的函数调用，返回值放入 a0 寄存器
• 从 ecall 中退出，ret 使得用户侧返回。

Sandbox with allowed pathnames

添加一个对于 open 和 exec 检查路径的功能。

阅读 hint，有这两步：

Some hints:

• Modify sys_interpose() to remember the allowed pathname. argstr will be handy to retrieve the pathname. You can declare a buffer of size MAXPATH in the proc struct.
• If open or exec are masked, check if the pathname matches the allowed pathname. If so, allow the execution of those system calls.

第一个很简单，照着做就行了。因为和上一题里面做的东西基本一样。

第二个，我遇到了一些困难：

我问语言模型：

得到的答案，总结一下：

• 这里的 0 不是 stdin，而是：读取系统调用的第 0 个参数，也就是第一个参数。

• a0, a1, ... 分别对应系统调用的第0，第1...个参数。

• 而这两个系统调用的函数形式（看源码就可以知道了，user.h，都是：

  open(path, mode);exec(path, argv);

• 因此，在 syscall()里面，使用 argstr(0, pathm MAXPATH) 就可以获得参数了。

Attack xv6

背景是，uvmalloc 和 kalloc 里面，省略了 memset 的几个语句，导致新分配的内存保留了其先前使用的内容。

然后运行这么一个程序：

#define DATASIZE (8*4096)char data[DATASIZE];intmain(int argc, char *argv[]){  if(argc != 2){    printf("Usage: secret the-secret\n");    exit(1);  }  strcpy(data, "This may help.");  strcpy(data + 16, argv[1]);  exit(0);}

编写 attack.c 以得到 secret.c 的这个 secret

具体做法需要用到一个系统调用 sbrk：向内核申请扩大当前进程的用户内存，返回值是指向新增加的这段内存的起始位置。

在 xv6 中通常声明为：

char *sbrk(int n);

那么解决方案就很简单了：

intmain(int argc, char *argv[]){  // Your code here.  char *p = sbrk(8*4096);  if (p == (char*)-1) {    exit(1);  }  for (int i = 0; i < 8*4096 - 16; i++) {    if (p[i] =='T') {      char tmp[15];      memcpy(tmp, p + i, 15);      if (!strcmp(tmp, "This may help.")) {        for (char *c = p + i + 16; *c; c++) {          printf("%c", *c);        }        printf("\n");      }    }  }  exit(1);}

总结和碎碎念

xv6 book 找不到比较新版的汉化，所以基本是直接丢给 LLM 让他总结一下我随便看看就上手写 lab 了。结果发现，写 lab 的时候遇到的基本上所有问题，在书里面都有解答，但是我开始写的时候就是一头雾水，有点难绷。

但是仔细想想，感觉我就算仔细读，也读不进去，反倒是我现在从开始的一头雾水，到一边写一边弄懂，可能这样对我而言效果更好一点。或许，现在可以去重新读一下这一部分的书？不过我现在有点懒，所以作罢吧。

阅读 xv6 book：

shell 是一个普通的程序，它读取用户的命令并执行它们。shell是一个用户程序，而不是内核的一部分，这一事实说明了系统调用接口的强大功能：shell没有什么特别的。这也意味着外壳易于更换；因此，现代Unix系统有多种shell可供选择，每种都有自己的用户界面和脚本功能。

xv6 提供的 system call：

cd 必须是 shell 的内置命令，因为：

假设 cd 是普通程序，Shell 会这样运行它：

Shell  │ fork  ▼子进程执行 cd

子进程执行：

chdir("/home");

改变的只是子进程自己的工作目录。随后子进程退出，原来的 Shell 目录完全没变。

因此 cd 必须由 Shell 自己执行：

Shell 进程直接调用 chdir()

这样才能真正改变后续命令使用的工作目录。

这是 1.4 中值得重点理解的例子，因为它再次体现：fork 后，父子进程的进程状态彼此独立。

关于 ping pong：

Write a program that uses UNIX system calls to “ping-pong” a byte between two processes over a pair of pipes, one for each direction. Measure the program’s performance, in exchanges per second.

代码：

#include <stdio.h>#include <stdlib.h>#include <time.h>#include <unistd.h>#define N_EXCHANGES 100000int main(int argc, char** argv) {    int pipe_child_to_parent[2];   // pipe_child_to_parent[0]=读端, [1]=写端    int pipe_parent_to_child[2];   // pipe_parent_to_child[0]=读端,  [1]=写端    char b = 'a';    if (pipe(pipe_child_to_parent) < 0 || pipe(pipe_parent_to_child) < 0) {        perror("Pipe error.");        // *** 问题：pipe 失败了但没有 exit(1)，程序会带着无效 fd 继续执行。        // 后面所有 read/write 都会操作 fd=-1，虽然不会崩溃但全部静默失败。        exit(1);    }    int pid = fork();    time_t start, end;    if (pid < 0) {        perror("fork error");        exit(1);        // *** 问题：fork 失败后没有 exit(1)，只有 perror。        // 程序会继续往下执行，进入 pid>0 或 pid==0 的未知分支。    } else if (pid == 0) {        // ============================================================        //  关键概念：fork 之后谁持有哪些 fd？        // ============================================================        //        // pipe() 创建的管道是内核对象。fd 只是"指向这个内核对象的编号"。        // fork() 会复制整个 fd 表，所以父子各自拥有独立的 fd 编号，但都        // 指向同一个内核管道。        //        // 创建了两条管道后：        //        //   pipe_parent_to_child[0] = 3  (读端)    父→子，父写子读        //   pipe_parent_to_child[1] = 4  (写端)        //   pipe_child_to_parent[0] = 5  (读端)    子→父，子写父读        //   pipe_child_to_parent[1] = 6  (写端)        //        // fork 之后，父子进程各有一份 fd 3,4,5,6，都指向同两个内核管道。        //        // 现在子进程的任务是：        //   - 从 pipe_parent_to_child 的读端读取父发来的数据 → 用 fd 3        //   - 向 pipe_child_to_parent 的写端把数据回给父   → 用 fd 6        // 所以子进程只用到 fd 3 和 fd 6。fd 4 和 fd 5 完全不用。        //        // ============================================================        //  什么时候需要 close？——两条铁律        // ============================================================        //        // 铁律 1：一个进程如果不打算在某条管道上"写"，就必须把自己持有        //         的该管道**所有写端 fd** 全部关掉。        //        // 铁律 2：一个进程如果不打算在某条管道上"读"，就必须把自己持有        //         的该管道**所有读端 fd** 全部关掉。        //        // ============================================================        //  为什么不关就会出事？——具体推演        // ============================================================        //        // 以 pipe_parent_to_child 这条管道为例：        //        //   fork 之后：父进程有 fd{3,4}，子进程也有 fd{3,4}        //   （3=读端，4=写端）        //        //   父进程会写这条管道（用 fd 4），子进程会读这条管道（用 fd 3）。        //   但子进程的 fd 4（写端）他从来不写，如果没关 ——        //        //   那会发生什么？        //        //   假设程序没有固定循环次数，而是"读到 EOF 才停"：        //        //     父进程：写了 10 次 → close(fd4) → 结束        //     子进程：while (read(fd3, ...) > 0) { ... }        //        //   问题是：子进程 read 的时候，内核看了一眼 pipe_parent_to_child        //   这个管道——"嗯...父进程关了写端，但子进程的 fd4（写端）还开着！        //   可能还有数据要来，我再等等..."——于是 read() 永远阻塞，子进程        //   永远不会从 while 循环里出来。        //        //   这就是"忘了 close 导致死锁"的经典场景。        //        //   你的代码靠固定循环次数 + 两个进程最后都 exit() 避免了这个问题，        //   但这是危险的——将来只要有一个读操作依赖 EOF 来判断结束，就会死锁。        //        // ============================================================        //  在哪里 close？——越早越好        // ============================================================        //        // 一旦你确定"这个进程不需要这个 fd 了"，就立刻 close。        // 对于 ping-pong 程序，在进入循环之前就应该关掉：        //        // ==================== 子进程：进入循环前应 close ====================        // *** 缺失：close(pipe_parent_to_child[1]);        // 原因：子进程永远不会向 pipe_parent_to_child 这条管道写数据。        // 写端 fd[1] 只有父进程在用。子进程留着写端=告诉内核"我也可能        // 写哦"，会导致铁律 1 被违反。        //        // *** 缺失：close(pipe_child_to_parent[0]);        // 原因：子进程永远不会从 pipe_child_to_parent 这条管道读数据。        // 读端 fd[0] 只有父进程在用。不关也会违反铁律 2。        // close 先关掉不用的 fd（铁律！）        close(pipe_parent_to_child[1]);  // 子进程不写 parent→child，关写端        close(pipe_child_to_parent[0]);  // 子进程不读 child→parent，关读端        for (int i = 0; i < N_EXCHANGES; ++i) {            // read 返回实际读到的字节数；期望读到 1 字节            int rt = read(pipe_parent_to_child[0], &b, 1);            if (rt != 1) {                // 读到 0 = 对方关了写端（EOF），-1 = 出错                perror("child read");                exit(1);            }            rt = write(pipe_child_to_parent[1], &b, 1);            if (rt != 1) {                perror("child write");                exit(1);            }        }        exit(0);    } else {        // ==================== 父进程 ====================        //        // 父进程的任务：        //   - 向 pipe_parent_to_child 写入数据         → 用 fd[1]（写端）        //   - 从 pipe_child_to_parent 读取子进程回传  → 用 fd[0]（读端）        //        // 不用的 fd（进入循环前必须关）：        //   pipe_parent_to_child[0]（读端）→ 父进程永远不会从这里读        //   pipe_child_to_parent[1]（写端）→ 父进程永远不会往这里写        //        // 不关的话：子进程将来如果想通过 read 返回 0（EOF）来判断        // "父进程写完了"，会因为父进程留着写端而永远等不到 EOF。        //        // 另外，你当前在第 143 行 close 的是 pipe_parent_to_child[1] 和        // pipe_child_to_parent[0]——这两个是父进程在循环中**正在使用**的        // 写端和读端。它们应该最后关（循环结束后）。        // 而本该先关的 pipe_parent_to_child[0] 和 pipe_child_to_parent[1]        // 却完全没有被 close。顺序完全搞反了。        //        // 正确的 close 布局：        //   close(pipe_parent_to_child[0]);   // ← 循环前：关掉不用的读端        //   close(pipe_child_to_parent[1]);   // ← 循环前：关掉不用的写端        //   for (...) { write(...); read(...); }  // ← 用自己需要的 fd        //   close(pipe_parent_to_child[1]);   // ← 循环后：用完再关        //   close(pipe_child_to_parent[0]);   // ← 循环后：用完再关        // *** 缺失：close(pipe_parent_to_child[0]);        // *** 缺失：close(pipe_child_to_parent[1]);        start = time(NULL);        // 父进程先关掉自己不用的 fd        close(pipe_child_to_parent[1]);  // 父进程不写 child→parent，关写端        close(pipe_parent_to_child[0]);  // 父进程不读 parent→child，关读端        for (int i = 0; i < N_EXCHANGES; ++i) {            // *** 关键：父进程先 write（发起 ping），再 read（等 pong）！            // 子进程那边是先 read 后 write，两边必须配对，            // 否则同时 read 就死锁。            int rt = write(pipe_parent_to_child[1], &b, 1);            if (rt != 1) {                perror("parent write");                exit(1);            }            rt = read(pipe_child_to_parent[0], &b, 1);            if (rt != 1) {                perror("parent read");                exit(1);            }        }        end = time(NULL);        double elapsed = difftime(end, start);        printf("每秒交换次数：%.2f\n", N_EXCHANGES / elapsed);        exit(0);    }}// 总结你的主要问题：//// 1. 【致命】父进程把读端和写端搞反了。//    记住口诀：pipe(fd) 之后，fd[0] 永远用来读，fd[1] 永远用来写。//    你父进程里 read(fd[1]) 和 write(fd[0]) 都反了。//// 2. 【重要】缺少 close 不用的 fd。//    在进入循环之前，每个进程应该关掉自己不需要的那两个 fd。//// 3. 【次要】pipe() 和 fork() 的错误处理不完整，失败后没有 exit。//// 4. 【次要】read/write 没有检查返回值，失败时静默将继续。

Boot xv6

根据 lab tools page 配置好在 WSL 下运行 xv6 的环境。

克隆好相应的代码。

输入 make qemu 以构建并运行 xv6。

查看进程：不是 ps，是 Ctrl + P

退出 qemu，输入： Ctrl-a x

sleep

#include "kernel/types.h"#include "kernel/stat.h"#include "kernel/fcntl.h"#include "user/user.h"int main(int argc, char* argv[]) {  if (argc != 2) {    fprintf(2, "Usage: sleep time...\n");    exit(1);  }  int ret = pause(atoi(argv[1]));  exit(ret);}

不过留下的疑问：

1. system call，在user.h 文件里面，在 vscode 里面点击「查看定义」，溯回不到汇编源码，那么，汇编源码是如何和 C 语言头文件结合的？
2. pause 的返回值，光看汇编也看不出来是什么

答案：脚本生成 + 链接器符号解析。日后再深究吧。

感觉是我没读 csapp 的缘故？有点一头雾水，说实话。没有一个高屋建瓴的架构视角的感觉有点不爽，毕竟在 LLM 时代，这个比较重要。

记得把文件加入 Makefile，不然重新编译内核也没用。

sixfive

这里重点是注意参数可以接多个。

memdump

这里注意 s 的实现：

case 's':   printf("%s\n", *(char**)d);   d += 8;   break;

先取出指针的指针，再解引用所指向的内容。

find

一个意外的 C 语言语法是：const 的指针可以执行运算，只是不能修改指向的内容。

换句话理解：const 修饰的是指向的内容，不是指针本身。

find with -exec

先上代码：

#include "kernel/types.h"#include "kernel/fcntl.h" // O_RDONLY#include "kernel/fs.h"    // struct dirent, DIRSIZ#include "kernel/stat.h"  // struct stat, T_DIR, T_FILE#include "kernel/param.h"#include "user/user.h" // open, read, close, fstat, printf...#define NULL 0voidcheck_path(const char *path, const char *name, char **cmd);intmain(int argc, char *argv[]){  if(argc < 3) {    fprintf(2, "Usage: find [path] [name] [-exec command ...]\n");    exit(1);  }  const char *path = argv[1];  const char *name = argv[2];  char **cmd = NULL;  if(argc > 3) {    if(strcmp(argv[3], "-exec") != 0) {      fprintf(2, "The third argument should be -exec.\n");      exit(1);    }    if(argc == 4) {      fprintf(2, "No command was provided after -exec.\n");      exit(1);    }    cmd = argv + 4;  }  check_path(path, name, cmd);  return 0;}voidcheck_path(const char *path, const char *name, char **cmd){  int fd = open(path, O_RDONLY);  struct stat st;  struct dirent de;  if(fd < 0) {    fprintf(2, "Can not open the path.\n");    return;  }  fstat(fd, &st);  if(st.type == T_DIR) {    while(read(fd, &de, sizeof(de)) == sizeof(de)) {      if(!strcmp(de.name, ".") || !strcmp(de.name, "..") || !de.inum) {        continue;      }      char buf[512];      strcpy(buf, path);      char *p = buf + strlen(buf); // p 指向 buf 末尾的 '\0'      *p++ = '/';      memmove(p, de.name, DIRSIZ);      p[DIRSIZ] = 0;      check_path(buf, name, cmd);    }  } else {    // 当前 path 即为完整路径，判断最后文件名是否符合即可    const char *p;    for(p = path + strlen(path); *p != '/' && p > path; p--)      ;    p++;    if(!strcmp(p, name)) {      // printf("%s\n", path);      if(!cmd) {        printf("%s\n", path);      } else {        int rc = fork();        if(rc < 0) {          fprintf(2, "fork failed.\n ");          exit(1);        } else if(rc == 0) {          char *new_cmd[MAXARG];          int i;          for(i = 0; cmd[i]; i++) {            new_cmd[i] = cmd[i];          }          new_cmd[i] = (char*)path;          new_cmd[i+1] = 0;          exec(new_cmd[0], new_cmd);          fprintf(2, "exec failed.\n");          exit(1);        } else {          wait(NULL);        }      }    }  }  close(fd);}

主要遇到的问题：

1. cmd 的逻辑这一块，太久没手写了，如何写得优雅卡了一会儿，不过其实感觉这个让语言模型代劳完全没问题，毕竟和 OS 没什么关系...试着把握好度吧。

2. 忘记处理参数了，开始直接写的是 exec(cmd[0], cmd)，没把 path 加进去。

3. de.inum == 0 的判断很重要，这里其实照抄 ls.c 就行，不过解释一下原因：

   把目录理解成一本有"已删除"标记的笔记本。

   文件系统删除文件时，并不会把目录里那条记录擦掉，也不会把后面的记录往前挪——太费劲了。它只做一件事：把 inum 改成 0。

   删除前：                      删除后：┌────────┬──────────────┐    ┌────────┬──────────────┐│ inum=5 │ name="cat"   │    │ inum=0 │ name="cat"   │  ← 名字还在！├────────┼──────────────┤    ├────────┼──────────────┤│ inum=7 │ name="ls"    │    │ inum=7 │ name="ls"    │├────────┼──────────────┤    ├────────┼──────────────┤│ inum=0 │ name(垃圾)    │    │ inum=0 │ name(垃圾)    │└────────┴──────────────┘    └────────┴──────────────┘

   那你遍历目录时会发生什么？

   read(fd, &de, sizeof(de)) → de.inum=0, de.name="cat"

   如果不检查 de.inum == 0，你会拿着 "cat" 这个名字去 open("cat")——但 cat 早就不存在了！

   更要命的是，空槽位里的 name 可能残留着任意旧数据。它可能恰好是一个有效的名字，导致你去 open 一个不该 open 的东西；或者更糟——在你这个递归场景下——引发预料之外的循环。

   ls.c 第 61 行做的就是这件事：

   if(de.inum == 0)        // 空座位，跳过    continue;

Lab1 完成：

Cloudflare Fundamentals docs

虽然不知道读这种服务性质的内容的文档干嘛，不过似乎 cf 的这个基础文档里面会讲很多有关的计网知识，所以看一看也没什么坏处。

文档只提供英文版，阅读文档的时候用的是 DeepSeek V4 Flash +沉浸式翻译插件翻译的版本。

另：cf 还有这么一个网站：Learning Center | Cloudflare

里面讲解更多实际的网络相关的知识，之后可以加以补充。

Cloudflare 的产品矩阵是真的庞大...

Overview

Cloudflare 自称是连接云网络，这个似乎是 cf 自创的一个概念，详情见 Welcome to connectivity cloud: the modern way to connect and protect your clouds, networks, applications and users | The Cloudflare Blog。

连接云是一种新方法，用于提供企业保护和连接数字环境所需的众多服务。它是一个统一的、智能的、可编程的云原生服务平台，能够实现所有网络（企业网络和互联网）、云环境、应用程序和用户之间的任意互联。它包括大量的安全、性能和开发服务——并非旨在全面取代现有的一切，而是能够根据需要灵活部署，并将许多关键服务整合到单一平台上。

Concepts

cf 作为 DNS 提供商

TODO：What is DNS? | Learning Center

cf 这个 learning center 的配套文档也太多了...感觉这辈子都看不完，只能在这画个饼了。

不过 DNS 的基础概念还是知道的，这里不写了。很多细节是 TODO，后面估计单独拆出来记。

cf 作为反向代理

所谓反向代理：一组位于 Web 服务器前方的服务器网络。

• 它们要么将请求转发给这些 Web 服务器，
• 要么代表 Web 服务器处理请求。

使用 cf 进行反向代理的优势：

• 负载均衡
• 缓存
• 防攻击
• SSL 加密

Docker——学过，看过，用过，都很零散，这次决定系统梳理一遍。

梳理一下我不太熟悉的东西：

• Docker Compose
• Docker 的网络相关

这次着重补一下这两块。

学习主线使用《Docker 从入门到实践》这本书，辅可能会有读到的文档和看的教学视频的内容加以补充。

Docker 简介

• 轻量级的虚拟化技术
• 将应用程序及其依赖环境可以被打包成一个标准化的单元，在满足架构、内核能力和外部依赖前提的环境中高度一致地运行。

和虚拟机的差别

传统虚拟机：

• 虚拟出一套完整的硬件，在其之上运行一个完整的 OS

Docker 容器：

• 容器运行与宿主的内核，容器没有自己的内核，没有对于硬件的虚拟

Docker 的优势

• 一次构建，到处运行
• 环境一致性
• 启动速度快
  • 对 CI/CD，弹性扩容很好
• 资源效率相比虚拟机高
• 持续交付和部署
  • 契合 DevOps 的工作流程：代码提交、
• 轻松迁移
• 微服务架构的基石

Docker 概念

镜像

• 只读的模板，包含运行应用所需要的一切。

  镜像只读，不包含动态数据，构建之后内容不改变。

• 一个镜像可以创建多个容器，而镜像本身保持不变。

镜像与 OS 的关系

OS 分为内核和用户空间：

flowchart TD    subgraph UserSpace ["用户空间"]        direction TB        App["应用程序、工具、库、配置文件...<br/>（这部分被打包成 Docker 镜像）"]    end    subgraph KernelSpace ["Linux 内核"]        direction TB        Kernel["容器共享宿主机的内核"]    end    UserSpace --- KernelSpace

Docker 容器：本质是一个自己的 root 文件系统，挂载在 OS 的内核之下运行，不包含自己的内核。

分层存储

分成很多层，每一层都是基于上一层运行的。

体现在 Dockerfile 的不同的行中。

举一个陷阱式的例子来理解：

## 错误示范 ❌FROM ubuntu:24.04RUN apt-get updateRUN apt-get install -y build-essential  # 安装编译工具（约 200MB）RUN make && make install                  # 编译应用RUN apt-get remove build-essential        # 试图删除编译工具## 结果：镜像仍然包含 200MB 的编译工具！

## 正确做法 ✅FROM ubuntu:24.04RUN apt-get update && \    apt-get install -y build-essential && \    make && make install && \    apt-get remove -y build-essential && \    apt-get autoremove -y && \    rm -rf /var/lib/apt/lists/*## 在同一层完成安装、使用、清理

镜像的标识

多种标识方式

• 镜像名称和标签：

  • 格式：[仓库地址/]仓库名[:标签]，但也有缩写形式，举例：
  • 完整格式 registry.example.com/myproject/myapp:v1.2.3
  • 简写，默认仓库地址为官方的 Docker Hub：nginx:1.28
  • 省略标签，nginx，等价于 nginx:latest

• 镜像 ID

  $ docker imagesREPOSITORY   TAG       IMAGE ID       CREATED        SIZEnginx        latest    a6bd71f48f68   2 weeks ago    187MBubuntu       24.04     ca2b0f26964c   3 weeks ago    78.1MB

  此处的 IMAGE ID 即为。

• 摘要

  • digest
  • 镜像内容的唯一标识
  • 推荐使用这个代替标签

容器

• 容器是镜像的运行实例。
• 如果把镜像比作程序，那么容器就是进程。
• 用 OOP 术语来说：镜像是类 (Class)，容器是对象 (Instance)。

容器的特征：

• 一个镜像可以创建多个容器
• 每个容器相互独立，互不影响
• 容器可以被创建、启动、停止、删除、暂停

容器的本质

容器的本质是一个特殊的进程。但是与一般的进程相比，有如下特质：

• 独立的进程空间：容器看不到宿主机上的其他进程。
• 独立网络环境：在默认网络模式下，容器通常拥有独立的网络命名空间，并可分配独立 IP；使用 host 或 container: 等模式时则例外。
• 独立文件系统：容器拥有独立的 root 目录。
• 独立的用户空间：鉴于我不是很理解 Linux 的用户空间，这里暂且 TODO。

容器的存储层

镜像层+容器层：假设容器基于的镜像有 $N$ 层，那么容器就是构建一个第 $N+1$ 层，可写，作为容器存储层。

Copy-on-Write 写时复制：

当容器需要修改镜像层中的文件时：

1. Docker 将该文件 复制 到容器存储层
2. 在容器层中进行修改
3. 原始镜像层保持不变

容器存储层的生命周期：和容器绑定，删除容器同时删除容器存储层。

数据持久化范式：Docker 的最佳实践认为容器存储层应该保持无状态性，如果需要保留，应当使用数据卷 / 绑定挂载。

容器的生命周期

存在的状态：

• Created
• Running
• Paused
• Stopped
• Deleted

容器和进程的关系

容器的生命周期 = 主进程 (PID 1) 的生命周期

运行：

docker run ubuntu

容器会立刻退出：默认启动的程序没有持续工作，PID 1 很快结束了。使用：

docker run -it ubuntu bash

则 bash 成为 PID 1；只要你不退出这个 shell，容器就会继续运行。

容器的隔离是如何实现的

使用 Linux 的 Namespace 机制。

Docker Registry

核心概念

Docker Registry 是存储和分发 Docker 镜像的服务，类似于代码的 GitHub 或包管理的 npm。

Docker Registry 中可以包含多个 Repository，每个 Repository 可以包含多个 Tag。

这也就是为什么，镜像的完整名称是 [registry 地址/][用户名/]仓库名[:标签]。

公共 Registry 服务

Docker Hub 是最大的公共 Registry，也是 Docker 的默认 Registry。

• 免费账户可以创建公开仓库
• 免费个人账户可创建 1 个私有仓库；更高套餐支持更多私有仓库

还有一些镜像源比如 Github Container Registry，Google 的，阿里巴巴的，腾讯的等。

可以配置镜像加速器来加速：

// /etc/docker/daemon.json{  "registry-mirrors": [    "https://your-accelerator-url"  ]}

私有 Registry

云厂商有提供服务，可以自己看，比如阿里云 ACR、腾讯云 TCR、AWS ECR 等。

有时需要使用 docker login 来登录到 Docker Registry。

镜像的推送和拉取

开发者机器                    Registry                    生产服务器     │                           │                             │     │  docker build             │                             │     │  构建镜像                  │                             │     │                           │                             │     │  docker push ─────────────▶                             │     │  推送镜像                  │  存储镜像                   │     │                           │                             │     │                           │  ◀───────────── docker pull │     │                           │                  拉取镜像    │     │                           │                             │     │                           │                  docker run │     │                           │                  运行容器    │

使用镜像

获取镜像

## 完整格式$ docker pull docker.io/library/ubuntu:24.04## 省略 Registry（默认 Docker Hub）$ docker pull library/ubuntu:24.04## 省略 library（官方镜像）$ docker pull ubuntu:24.04## 省略标签（默认 latest）$ docker pull ubuntu## 拉取第三方镜像$ docker pull bitnami/redis:latest## 从其他 Registry 拉取$ docker pull ghcr.io/username/myapp:v1.0

下载内容解析

$ docker pull ubuntu:24.0424.04: Pulling from library/ubuntu92dc2a97ff99: Pull completebe13a9d27eb8: Pull completec8299583700a: Pull completeDigest: sha256:4bc3ae6596938cb0d9e5ac51a1152ec9dcac2a1c50829c74abd9c4361e321b26Status: Downloaded newer image for ubuntu:24.04docker.io/library/ubuntu:24.04

可以看到镜像是分层下载的。

关于摘要

查看镜像摘要：

$ docker images --digests ubuntuREPOSITORY   TAG     DIGEST                                                                    IMAGE IDubuntu       24.04   sha256:4bc3ae6596938cb0d9e5ac51a1152ec9dcac2a1c50829c74abd9c4361e321b26   ca2b0f26964c

然后使用摘要拉取：

$ docker pull ubuntu@sha256:4bc3ae6596938cb0d9e5ac51a1152ec9dcac2a1c50829c74abd9c4361e321b26

磁盘空间不足的解决方案

## 清理未使用的镜像$ docker image prune## 清理所有未使用资源$ docker system prune

查看镜像

基本用法

$ docker imagesREPOSITORY   TAG       IMAGE ID       CREATED        SIZEredis        latest    5f515359c7f8   5 days ago     183MBnginx        latest    05a60462f8ba   5 days ago     181MBubuntu       24.04     329ed837d508   3 days ago     78MBubuntu       noble     329ed837d508   3 days ago     78MB

理解镜像的大小

本地大小和 Docker Hub 显示的大小：

• 前者是本地解压后的实际大小
• 后者是压缩后的网络传输大小

实际磁盘占用：

• 由于镜像分层存储，不同的镜像共享不同的层
• 故 $\sum{\text{size}} \gt \text{实际磁盘占用}$。

如何查看实际空间的占用：

$ docker system dfTYPE            TOTAL   ACTIVE   SIZE      RECLAIMABLEImages          15      3        2.5GB     1.8GB (72%)Containers      5       2        100MB     80MB (80%)Local Volumes   8       2        500MB     400MB (80%)Build Cache     0       0        0B        0B

查找特定的镜像（过滤镜像）

按镜像名过滤：

$ docker images ubuntu$ docker images ubuntu:24.04

使用过滤器：

--filter -f

有一系列的过滤条件，这个感觉记了也记不住，知道就好。

虚悬镜像 dangling images

仓库名和标签都显示为 <none> 的镜像。

产生原因：

• 镜像重新构建：新镜像使用了旧镜像的标签，旧镜像标签被移除
• docker pull 更新：拉取更新版本时，旧版本失去标签（latest）

处理方式：

• 列出：docker images -f dangling=true
• 删除：docker image prune

中间层镜像

docker images 只列出顶层镜像，为了查看中间镜像，使用 docker images -a。

格式化输出

主要是命令之间的搭配使用。

只输出 ID：docker images -q

举例：删除所有 redis 镜像：docker rmi $(docker images -q redis)

显示摘要：docker images --digests

删除镜像

基本用法

$ docker image rm [选项] <镜像1> [<镜像2> ...]

镜像标识方式

• 短 ID（可以标识的前几位）
• 完整 ID
• 镜像名:标签
• 镜像摘要
  • 最精确，适合 CI/CD 场景

删除镜像的输出信息

$ docker rmi redis:alpineUntagged: redis:alpineUntagged: redis@sha256:f1ed3708f538b537eb9c2a7dd50dc90a706f7debd7e1196c9264edeea521a86dDeleted: sha256:501ad78535f015d88872e13fa87a828425117e3d28075d0c117932b05bf189b7Deleted: sha256:96167737e29ca8e9d74982ef2a0dda76ed7b430da55e321c071f0dbff8c2899bDeleted: sha256:32770d1dcf835f192cafd6b9263b7b597a1778a403a109e2cc2ee866f74adf23

• Untagged：移除镜像的标签
• Deleted：删除镜像的存储层

删除流程：

先检查指向该镜像的标签并逐个 untag，然后再逐层删除镜像，被使用则保留，不被使用则删除。

批量删除

这里大概自然语言描述一下能做到哪些吧：

• 删除所有虚悬镜像，docker image prune
• 删除一段时间内未使用的镜像：docker image prune -a --filter "until=24h"
• 按照条件删除，比如：
  • 删除所有 redis 镜像
  • 删除某个时间点之前的镜像
  • 删除某个版本号之前的镜像

删除失败的原因

• 存在容器依赖这个镜像
• 这个镜像作为中间层被其他镜像依赖
• 多个标签指向同一个镜像，比如 ubuntu 的 24.04 和 latest 同时指向同一个 IMAGE ID

清理策略

开发环境：

• 定期清理 dangling images
• 清理未使用的资源 docker system prune -a

CI/CD：

• 只保留最近使用过的镜像（即一键删除一段时间内未使用过的镜像）

查看空间占用：

• docker system df

使用 docker commit

把某个容器当前在文件系统上的改动，固化成一个新的 Docker 镜像。

命令格式：

$ docker commit [OPTIONS] 容器名或容器ID 新镜像名[:标签]

举个例子，进入容器之后，修改了里面文件系统的一些内容，

执行

docker commit dev my-ubuntu:v1

实际上做的：

原镜像的只读层 + dev 容器的可写层 -> 转化成新的只读镜像层 -> 新的镜像

原理是让新镜像继续复用原来的镜像层，再增加一层，用来保存这个容器相对于原镜像产生的文件系统变化。

缺点

使用 docker commit 定制的镜像存在如下问题：

• 执行命令会连着根式地修改一大堆无关的文件，可以通过 docker diff webserver 看出；
• 对镜像的操作都是黑箱操作；
• 层数会膨胀

使用 Dockerfile 定制镜像

解决上面所说的问题。

Dockerfile 是一个包含了一条条的指令的文本文件：

• 会修改文件系统的指令通常会创建新层；
• 而 LABEL、CMD 这类只修改镜像元数据的指令，则不会新增文件系统层。

创建 Dockerfile

比较详细的命令后面单开一节介绍。

FROM 指定基础镜像：

所谓定制镜像，是以一个镜像为基础，在其上进行定制。所以需要 FROM 指定的基础镜像。

除了选择现有镜像为基础镜像外，Docker 还存在一个特殊的镜像，名为 scratch。这个镜像是虚拟的概念，并不实际存在，它表示一个空白的镜像。

FROM scratch...

如果以 scratch 为基础镜像的话，意味着你不以任何镜像为基础，接下来所写的指令将作为镜像第一层开始存在。

不以任何系统为基础，直接将可执行文件复制进镜像的做法并不罕见，对于 Linux 下静态编译的程序来说，并不需要有操作系统提供运行时支持，所需的一切库都已经在可执行文件里了，因此直接 FROM scratch 会让镜像体积更加小巧。使用 Go 语言开发的应用很多会使用这种方式来制作镜像，这也是有人认为 Go 是特别适合容器微服务架构的语言的原因之一。

RUN 执行命令行命令：

• shell 格式：RUN <命令>
• exec 格式：RUN ["可执行文件", "参数1", "参数2"]

构建镜像

docker build [选项] <上下文路径/URL/->

执行之后的输出，含义还挺明显的，没什么必要单独扯出来记。

镜像构建上下文

关于什么是上下文路径：构建器可以访问到的文件集合。

比如 Dockerfile 里面会写 COPY 和 RUN 指令，假设有这样的：

COPY ./package.json /app/

这里复制的就是上下文目录下的 package.json。

而假设写成：

COPY ../package.json /app

这里的 .. 属于越界，构建器都无法读取上下文之外的宿主机文件。

由此可见，上下文，和 Dockerfile 所在的目录，没有关系。假设把上下文直接指定成 / ，理论是可行的，不过 BuildKit 的可见上下文会过大导致构建缓慢甚至失败。

而所谓的 .dockerignore 文件（通常置于项目根目录下，和 Dockerfile 平级，采用和 .gitignore 一样的 Glob 语法），就是为了忽略掉在构建时不希望传给 Docker 引擎的文件。

其余 docker build 的用法

• 从 Git Repo 中构建
• 用给定的压缩包构建
• 从标准输入中读取 Dockerfile 进行构建 cat Dockerfile | docker build -

操作容器

启动

启动容器有两种方式：

• 新建并启动：基于镜像创建新容器 docker run
• 重新启动：将已终止的容器重新运行 docker start

由于 Docker 容器非常轻量，实际使用中常常是随时删除和新建容器，而不是反复重启同一个容器。

新建并启动

docker run [选项] 镜像 [命令] [参数...]

交互式容器：

$ docker run -it ubuntu:24.04 /bin/bashroot@af8bae53bdd3:/#

启动选项

端口映射：

## 将容器的 80 端口映射到宿主机的 8080 端口$ docker run -d -p 8080:80 nginx:latest## 只绑定到 localhost$ docker run -d -p 127.0.0.1:8080:80 nginx:latest

映射端口这一点很重要，比如像 nginx 等服务，不暴露出端口，外部根本无法访问。

数据卷挂载

略，懒得记了

环境变量

## 设置单个环境变量$ docker run -e MYSQL_ROOT_PASSWORD=secret mysql## 从文件加载环境变量$ docker run --env-file .env myapp

这个倒是，容器有时候是需要诸如 .env 文件里面的环境变量的，假设 .dockerignore 了之后。

但是感觉把 .env 文件 docker ignore 掉的意义也不大，为什么要这样做呢？

Answer from ChatGPT，我归纳一下：

首先，肯定不能把 .env 放进镜像中啊（回忆一下本节的标题「新建并启动」），因为镜像是要分发的，分发出去，直接访问里面的 .env 文件不完蛋了，所以肯定要忽略掉。

其次，这样做的话，镜像和运行环境就解耦合了。

资源限制：

## 限制内存$ docker run -m 512m nginx:latest## 限制 CPU$ docker run --cpus=1.5 nginx:latest

重新启动容器

使用 docker start，后面跟上容器名。

获取容器名，使用 docker ps -a。

守护态运行

当在终端运行一个程序时，有两种模式：

• 前台运行：程序占用当前终端，输出直接显示，关闭终端程序就停止
• 后台运行：程序在后台执行，不占用终端，终端关闭也不影响程序

Docker 容器默认是 前台运行 的。使用 -d (detach) 参数可以让容器在后台运行。

理解为什么容器会立即退出

核心原理：容器的生命周期与主进程绑定。

举个例子，即使使用了 -d 参数运行：

$ docker run -d ubuntu:24.04

再使用 docker ps 也看不见容器在运行，原因：

1. 容器启动
2. 没有指定命令，默认执行 /bin/bash
3. 但没有交互式终端 (没有 -it 参数)，bash 发现没有输入源
4. bash 立即退出
5. 主进程退出，容器停止

查看容器

$ docker container ls$ docker ps# 前者是后者的简写# 查看日志$ docker container logs 77b2dc01fe0f# 实时查看日志$ docker container logs -f 77b2dc01fe0f

终止

docker stop 优雅终止

docker kill 直接终止

进入容器

-d 启动之后，有时候需要进入容器进行操作。

## 进入容器并启动交互式 shell$ docker exec -it 容器名 /bin/bash## 或使用 sh（适用于 Alpine 等精简镜像）$ docker exec -it 容器名 /bin/sh

导入和导出

docker export docker import

删除

docker rm

Dockerfile 指令详解

数据管理

数据卷

首先需要 $ docker volume create my-vol 创建一个数据卷，然后新建容器的时候，使用 --mount 或者 -v 挂载数据卷。

挂载主机目录

docker run -v mydata:/app/data nginx# 名为 mydata 的数据卷，映射到容器的 /app/data 目录

docker run -v /home/user/data:/app/data nginx

网络配置

刚刚（2026-07-04 22:55）数据库出了个分，

我感觉很多王道原题

2. 填空 1%*10

操作系统是管理（）的软件

共享变量属于（）资源

磁盘性能评估时间的三个指标（）（）（）

3. 判断 1%*10

忘了有什么了

4. 简答 5%*4

非抢占式和抢占式调度哪个更消耗系统资源，给出原因