courselab: add mit 6_1810 2022 xv6 labs

Author: tareknaser

benchmarks/courselab_bench/data/courses.json

@@ -27,6 +27,13 @@
       "institution": "CMU",
       "year": 2024,
       "num_tasks": 1
+    },
+    {
+      "course_id": "mit_6_1810_2022",
+      "name": "MIT 6.1810: Operating System Engineering",
+      "institution": "MIT",
+      "year": 2022,
+      "num_tasks": 10
     }
   ]
 }

benchmarks/courselab_bench/data/mit_6_1810_2022/docker/Dockerfile

@@ -0,0 +1,17 @@
+FROM ubuntu:22.04
+
+ENV DEBIAN_FRONTEND=noninteractive
+
+RUN apt-get update && apt-get install -y --no-install-recommends \
+    build-essential \
+    gcc-riscv64-linux-gnu \
+    qemu-system-misc \
+    python3 \
+    git \
+    ca-certificates \
+    ipxe-qemu \
+    && rm -rf /var/lib/apt/lists/*
+
+WORKDIR /root/workspace
+
+CMD ["/bin/bash"]

benchmarks/courselab_bench/data/mit_6_1810_2022/docker/README.md

@@ -0,0 +1,6 @@
+Docker image for the System Intelligence Benchmark's CourseLab tasks for MIT 6.1810 Operating System Engineering labs.
+
+```bash
+docker build -t sysintelligence/xv6:latest .
+docker push sysintelligence/xv6:latest
+```

benchmarks/courselab_bench/data/mit_6_1810_2022/task_10_mmap/compose.yaml

@@ -0,0 +1,9 @@
+services:
+  default:
+    image: sysintelligence/xv6:latest
+    init: true
+    command: tail -f /dev/null
+    working_dir: /root/workspace
+    network_mode: bridge
+    cpus: '8.0'
+    mem_reservation: 8gb

benchmarks/courselab_bench/data/mit_6_1810_2022/task_10_mmap/config.json

@@ -0,0 +1,22 @@
+{
+  "instance_id": "mit_6_1810_2022__mmap",
+  "course_id": "mit_6_1810_2022",
+  "timeout_minutes": 60,
+  "tags": ["operating-systems", "c", "memory-mapping", "virtual-memory", "xv6", "risc-v", "kernel"],
+  "artifacts": [
+    "Makefile",
+    "kernel/defs.h",
+    "kernel/param.h",
+    "kernel/printf.c",
+    "kernel/proc.c",
+    "kernel/proc.h",
+    "kernel/riscv.h",
+    "kernel/syscall.c",
+    "kernel/syscall.h",
+    "kernel/sysproc.c",
+    "kernel/trap.c",
+    "user/user.h",
+    "user/usys.pl",
+    "time.txt"
+  ]
+}

benchmarks/courselab_bench/data/mit_6_1810_2022/task_10_mmap/evaluate.sh

@@ -0,0 +1,25 @@
+#!/bin/bash
+set -e
+
+cd /root/workspace
+
+# Verify protected files unchanged
+for file in grade-lab-mmap gradelib.py user/mmaptest.c; do
+    checksum="/tmp/checksums/$(echo "$file" | tr '/' '_').sha256"
+    if [ -f "$checksum" ]; then
+        sha256sum -c "$checksum" > /dev/null 2>&1 || { echo "FAIL: $file modified"; exit 1; }
+    fi
+done
+
+# Run grading with retries (tests can be timing-sensitive)
+for attempt in 1 2 3; do
+    if make LAB=mmap grade 2>&1 | tee /tmp/grade_output.txt | grep -q "Score:.*140/140"; then
+        echo "PASS: All tests passed"
+        exit 0
+    fi
+    [ $attempt -lt 3 ] && sleep 2
+done
+
+echo "FAIL: Tests did not pass"
+cat /tmp/grade_output.txt
+exit 1

benchmarks/courselab_bench/data/mit_6_1810_2022/task_10_mmap/preprocess.sh

@@ -0,0 +1,19 @@
+#!/bin/bash
+set -e
+
+
+cd /root
+
+# Clone MIT xv6-labs-2022 skeleton (mmap branch)
+git clone git://g.csail.mit.edu/xv6-labs-2022 workspace
+cd workspace
+git checkout mmap
+# Pin to specific commit for reproducibility
+git checkout 9cc6b8345397c1f06cc93ed3fbaa20709cb1984e
+rm -rf .git
+
+# Create checksums for protected files (grading scripts, tests)
+mkdir -p /tmp/checksums
+sha256sum grade-lab-mmap > /tmp/checksums/grade-lab-mmap.sha256
+sha256sum gradelib.py > /tmp/checksums/gradelib.py.sha256
+sha256sum user/mmaptest.c > /tmp/checksums/user_mmaptest.c.sha256

benchmarks/courselab_bench/data/mit_6_1810_2022/task_10_mmap/sol.sh

@@ -0,0 +1,31 @@
+#!/bin/bash
+# Reference solution from: https://github.com/Cyrus-iwnl/xv6-labs-2022
+set -e
+
+# Clone reference solution repository
+git clone https://github.com/Cyrus-iwnl/xv6-labs-2022.git /tmp/ref
+cd /tmp/ref
+git checkout origin/mmap
+
+# Copy solution files
+cp Makefile /root/workspace/
+cp kernel/defs.h /root/workspace/kernel/
+cp kernel/param.h /root/workspace/kernel/
+cp kernel/printf.c /root/workspace/kernel/
+cp kernel/proc.c /root/workspace/kernel/
+cp kernel/proc.h /root/workspace/kernel/
+cp kernel/riscv.h /root/workspace/kernel/
+cp kernel/syscall.c /root/workspace/kernel/
+cp kernel/syscall.h /root/workspace/kernel/
+cp kernel/sysproc.c /root/workspace/kernel/
+cp kernel/trap.c /root/workspace/kernel/
+cp user/user.h /root/workspace/user/
+cp user/usys.pl /root/workspace/user/
+
+cd /root/workspace
+
+# Create time.txt (required by grading script - contains hours spent)
+echo "1" > time.txt
+
+# Clean up
+rm -rf /tmp/ref

benchmarks/courselab_bench/data/mit_6_1810_2022/task_10_mmap/task.md

@@ -0,0 +1,93 @@
+# Lab: mmap (hard)
+
+The `mmap` and `munmap` system calls allow UNIX programs to exert detailed control over their address spaces. They can be used to share memory among processes, to map files into process address spaces, and as part of user-level page fault schemes such as garbage-collection algorithms. In this lab you'll add `mmap` and `munmap` to xv6, focusing on memory-mapped files.
+
+The manual page (run `man 2 mmap`) shows this declaration for mmap:
+
+```c
+void *mmap(void *addr, size_t length, int prot, int flags,
+           int fd, off_t offset);
+```
+
+`mmap` can be called in many ways, but this lab requires only a subset of its features relevant to memory-mapping a file. You can assume that `addr` will always be zero, meaning that the kernel should decide the virtual address at which to map the file. `mmap` returns that address, or 0xffffffffffffffff if it fails. `length` is the number of bytes to map; it might not be the same as the file's length. `prot` indicates whether the memory should be mapped readable, writeable, and/or executable; you can assume that `prot` is `PROT_READ` or `PROT_WRITE` or both. `flags` will be either `MAP_SHARED`, meaning that modifications to the mapped memory should be written back to the file, or `MAP_PRIVATE`, meaning that they should not. You don't have to implement any other bits in flags. `fd` is the open file descriptor of the file to map. You can assume offset is zero (it's the starting point in the file at which to map).
+
+It's OK if processes that map the same `MAP_SHARED` file do **not** share physical pages.
+
+`munmap(addr, length)` should remove mmap mappings in the indicated address range. If the process has modified the memory and has it mapped `MAP_SHARED`, the modifications should first be written to the file. An munmap call might cover only a portion of an mmap-ed region, but you can assume that it will either unmap at the start, or at the end, or the whole region (but not punch a hole in the middle of a region).
+
+You should implement enough `mmap` and `munmap` functionality to make the mmaptest test program work. If mmaptest doesn't use a mmap feature, you don't need to implement that feature.
+
+When you're done, you should see this output:
+
+```
+$ mmaptest
+mmap_test starting
+test mmap f
+test mmap f: OK
+test mmap private
+test mmap private: OK
+test mmap read-only
+test mmap read-only: OK
+test mmap read/write
+test mmap read/write: OK
+test mmap dirty
+test mmap dirty: OK
+test not-mapped unmap
+test not-mapped unmap: OK
+test mmap two files
+test mmap two files: OK
+mmap_test: ALL OK
+fork_test starting
+fork_test OK
+mmaptest: all tests succeeded
+$ usertests -q
+usertests starting
+...
+ALL TESTS PASSED
+$
+```
+
+Here are some hints:
+
+- Start by adding `_mmaptest` to `UPROGS`, and `mmap` and `munmap` system calls, in order to get `user/mmaptest.c` to compile. For now, just return errors from mmap and munmap. We defined `PROT_READ` etc for you in `kernel/fcntl.h`. Run mmaptest, which will fail at the first mmap call.
+- Fill in the page table lazily, in response to page faults. That is, mmap should not allocate physical memory or read the file. Instead, do that in page fault handling code in (or called by) `usertrap`, as in the lazy page allocation lab. The reason to be lazy is to ensure that mmap of a large file is fast, and that mmap of a file larger than physical memory is possible.
+- Keep track of what mmap has mapped for each process. Define a structure corresponding to the VMA (virtual memory area), recording the address, length, permissions, file, etc. for a virtual memory range created by mmap. Since the xv6 kernel doesn't have a memory allocator in the kernel, it's OK to declare a fixed-size array of VMAs and allocate from that array as needed. A size of 16 should be sufficient.
+- Implement mmap: find an unused region in the process's address space in which to map the file, and add a VMA to the process's table of mapped regions. The VMA should contain a pointer to a `struct file` for the file being mapped; mmap should increase the file's reference count so that the structure doesn't disappear when the file is closed (hint: see `filedup`). Run mmaptest: the first mmap should succeed, but the first access to the mmap-ed memory will cause a page fault and kill mmaptest.
+- Add code to cause a page-fault in a mmap-ed region to allocate a page of physical memory, read 4096 bytes of the relevant file into that page, and map it into the user address space. Read the file with `readi`, which takes an offset argument at which to read in the file (but you will have to lock/unlock the inode passed to `readi`). Don't forget to set the permissions correctly on the page. Run mmaptest; it should get to the first munmap.
+- Implement munmap: find the VMA for the address range and unmap the specified pages (hint: use `uvmunmap`). If munmap removes all pages of a previous mmap, it should decrement the reference count of the corresponding `struct file`. If an unmapped page has been modified and the file is mapped `MAP_SHARED`, write the page back to the file. Look at `filewrite` for inspiration.
+- Ideally your implementation would only write back `MAP_SHARED` pages that the program actually modified. The dirty bit (D) in the RISC-V PTE indicates whether a page has been written. However, mmaptest does not check that non-dirty pages are not written back; thus you can get away with writing pages back without looking at D bits.
+- Modify `exit` to unmap the process's mapped regions as if munmap had been called. Run mmaptest; mmap_test should pass, but probably not fork_test.
+- Modify `fork` to ensure that the child has the same mapped regions as the parent. Don't forget to increment the reference count for a VMA's `struct file`. In the page fault handler of the child, it is OK to allocate a new physical page instead of sharing a page with the parent. The latter would be cooler, but it would require more implementation work. Run mmaptest; it should pass both mmap_test and fork_test.
+
+Run `usertests -q` to make sure everything still works.
+
+---
+
+## Environment
+
+The workspace is at `/root/workspace`. The environment includes:
+
+- RISC-V cross-compiler (`riscv64-linux-gnu-gcc`)
+- QEMU system emulator (`qemu-system-riscv64`)
+- All necessary build tools
+
+## Files to Modify
+
+- `kernel/proc.h`
+- `kernel/proc.c`
+- `kernel/trap.c`
+- `kernel/sysfile.c`
+- `kernel/syscall.h`
+- `kernel/syscall.c`
+- `user/user.h`
+- `user/usys.pl`
+- `Makefile`
+- `time.txt` (create)
+- `answers-mmap.txt` (create)
+
+## Important Notes
+
+- Do NOT modify any grading scripts (`grade-lab-mmap`, `gradelib.py`) or test files (`user/mmaptest.c`)
+- Run `./grade-lab-mmap` to test your solutions
+- Run `make qemu` to build and test interactively in the xv6 shell
+- Run `usertests -q` to verify you haven't broken other kernel functionality

benchmarks/courselab_bench/data/mit_6_1810_2022/task_1_util/compose.yaml

@@ -0,0 +1,9 @@
+services:
+  default:
+    image: sysintelligence/xv6:latest
+    init: true
+    command: tail -f /dev/null
+    working_dir: /root/workspace
+    network_mode: bridge
+    cpus: '8.0'
+    mem_reservation: 8gb