Implement Copy-on-Write (COW) for fork() Efficiency

fork() Without Copying Everything

Copy-on-write (COW) lets fork() mark writable pages read-only in parent and child. The first writer faults, the kernel duplicates the frame, and updates both page tables. Most pages never get written after fork, so memory use stays low.

COW Fault Flow

Steps on write to shared page:

• CPU traps with write to read-only PTE
• Kernel allocates new frame, copies old contents
• Remaps writer's PTE writable; other may stay shared read-only

For example, after fork(), a 1 GB heap mapped but barely modified might share 99% of frames until specific objects mutate.

Why This Matters in Production

Every fork() on Linux relies on copy-on-write to make process creation cheap, and Redis's BGSAVE forks its entire dataset to get a consistent snapshot using this exact mechanism. The 2016 Dirty COW vulnerability (CVE-2016-5195) exploited a race in this very write-fault path to let unprivileged users gain root, showing COW correctness is a security property, not just a performance one.

Debugging Checklist

Before you call the implementation done, walk failure modes on purpose. Test empty structures, single-element edge cases, maximum concurrency, and errno paths that must not crash the program. OS code usually fails in production when happy-path tests pass but invariants break under contention or memory pressure.

Implementation Notes

Keep structures small and name fields after kernel counterparts when possible. That lets you read man pages and kernel source side by side while you work. Print observable events during development; remove noisy logs once tests pass reliably.

For This Exercise

You will implement COW bits on fork() simulation and duplicate frames on write faults. This task ties directly to why Linux can spawn processes faster than eager duplication would allow.