1

The copy-on-write article on wikipedia says that copy-on-write is usually implemented by giving read only access to the pages, so that when one is written, the page fault trap handler can map a unique physical memory page for it. So my question is why a user-level application doesn't receive a SIGSEGV signal when such page fault happens? Afterall, the wikipedia article on SIGSEGV says that SIGSEGV is the signal sent to a process when it makes an invalid memory reference, or segmentation fault. So in this case, that is on copy-on-write case, why no SIGSEGV is sent to the process.

Alexey Frunze
  • 61,140
  • 12
  • 83
  • 180
pythonic
  • 20,589
  • 43
  • 136
  • 219

2 Answers2

4

I know it's been a while since this was asked, but I wanted to expand on Alexey's answer a bit.

Copy-on-write (I assume you're talking about virtual memory and not filesystems) usually works like so:

  1. The OS knows which pages need to be copied on write. (They are the pages which are private to a process.) These pages are marked in hardware as read-only. However, the virtual memory map of the process has the pages marked as readable and writable. This means that the user process believes it has full access to the pages in question.
  2. When a user process attempts to write to one of these pages, a page fault is generated because the processor recognizes that the page is read-only (based on the hardware marks before). Page faults are sort of like segfaults, but for the kernel instead of for user processes.
  3. This triggers the page fault handler to run within the kernel, which looks at the page in question and sees that it's a private page which has not yet been copied. The handler will create a copy of the page and mark the copy as writable.
  4. Then the handler will replace the old page's address with the new one in the virtual-to-physical translation table and exit.
  5. The last instruction will be retried by the user process at this point, and this time the write will succeed because the new page is writeable at both the virtual memory map (the user process' view of memory permissions) and hardware (the kernel's view of memory permissions) levels.

A page fault is generated every time a segmentation fault occurs, but most page faults are handled by the kernel and are never passed to the process that caused them as segfaults. There are many reasons why a page fault might be handled at a lower level, including:

  • The page which was accessed was paged out to disk because it hadn't been used in a long time. The OS must bring it back into memory so the process can use it again.
  • The process is accessing a newly-allocated page for the first time, and the actual physical page hasn't been allocated yet. The OS must allocate a page and then insert it into the virtual-to-physical translation table before the memory can actually be used.
  • The OS is playing a hardware page access permissions trick to allow it to watch for accesses to a particular page. This is what happens in copy-on-write, but it can have other uses as well. Consider an OS-level virtualization technology like kvm, where writing to a memory-mapped device's location in memory in the guest OS should actually write to a file or the display in the host OS.
Dan
  • 7,155
  • 2
  • 29
  • 54
1

The main idea of COW is that COW is completely transparent to the user process as if it fully owned the memory without any sharing.

Alexey Frunze
  • 61,140
  • 12
  • 83
  • 180
  • But what happens when a process replicates itself on fork? I mean after the fork, if original process modifies some page, a new physical page is allocated to it, but if the forked process modifies the same page afterwards, its not allocated some new page because the original process now already has a different one. How is this achieved? – pythonic Apr 21 '12 at 03:49
  • The OS takes care of all of this page fault handling, memory allocation and mapping and data copying. – Alexey Frunze Apr 21 '12 at 03:51
  • user1018562, after fork parent's memory is COWed - marked as readonly, because there is now other process which links to the same memory. If anybody of them writes, it will get pagefault and page will be split (deCOWed). Kernel will allocate new page, do a copy of old data and then restart the failed write. It is transparent to user except the increased minor pagefault counter (check with /usr/bin/time). PS: fork+exec is a special case. – osgx Dec 19 '12 at 08:45