= Copy-on-write fault handling
The <operating-system kernel> must distinguish a temporarily protected <copy-on-write> mapping from one whose writes are forbidden. The teaching procedure in MIT's xv6 lab protects both <page tables>, copies the shared <page frame> on a valid write <page fault>, and installs a writable <page table entry>. Originally read-only code remains read-only. Its <reference counting> increments on sharing and decrements on removal; storage is freed only after the last reference disappears. The lab also requires kernel writes into user storage to respect <copy-on-write>, and specifies failure if no free storage remains. <6.1810 and Fall 2022/Lab: Copy-on-Write Fork for xv6>{ref}
Every write must respect the sharing policy, but every write need not copy. Repeated writes to B's already private writable F3 need no further <copy-on-write> <page fault>. If A later writes F0, an implementation can reuse F0 when it establishes exclusive, writable ownership; A's remaining read-only <page table entry> may still need a <page fault> to enable the write. This exclusive-reuse rule is an assumption of <copy-on-write page accounting> below, not a promise that every <operating system> uses that path. A count of one alone is not a universal permission to alter storage belonging to a <memory-mapped file> or another owner.
Changing mappings or permissions must also make cached <address translations> consistent. <Cache and TLB Flushing Under Linux by David S. Miller>{ref} Concurrent <software threads> require <synchronization> around ownership checks, copying, and installation to prevent a <race condition>; neither diagrams nor counts specify a production <operating-system kernel>'s locking or hardware invalidation protocol.
Back to article page
