fork() and Copy On Write

[sting sting]

Hello,
From all what I had read on the Linux Kernel I understand
that when we call fork() from an application then a new proess
is created, and its memory is copied from the process that
created it but it is now SHARED and READ-ONLY.

My architecture is Intel x86.

I had tried to locate where exactly in the sources this happens;
(namely , where is setting to SHARED and READ-ONLY made for the new
process).

I had looked at kernel/fork.c in 2.4.20 (and also 2.6.7) kernel.

In 2.4.20,there is a method named do_fork(); what seems relevant to memory
copying seems to me the call inside to copy_mm() which calls dup_mm().

I had looke at the code of theses methods and could not find a code where
there is a setting to SHARED and READ-ONLY for the pages
of the memory for the new process; any idea?

I want to clarify one more thing: I assume that the memory of the old
process which called fork() remains with the same privileges as it was
before calling fork
(Namely , if it was R/W before fork() it will stay R/W also after fork()).

Regards,
Sting

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/


--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive: http://mail.nl.linux.org/kernelnewbies/
FAQ: http://kernelnewbies.org/faq/

[Ed L Cashin]

Post by sting sting
Hello,
From all what I had read on the Linux Kernel I understand
that when we call fork() from an application then a new proess
is created, and its memory is copied from the process that
created it but it is now SHARED and READ-ONLY.
My architecture is Intel x86.
I had tried to locate where exactly in the sources this happens;
(namely , where is setting to SHARED and READ-ONLY made for the new
process).

A couple of years ago I was a lot more intimate with this stuff, but I
don't think that private pages are marked shared after a fork.
Rather, the copy-on-write status of a page is defined (or was in early
2.6 kernels and probably hasn't changed) by this:

* page protections say that the page is not writable

* vma protections say that the memory region is writable

Those two facts together mean that the page is copy on write.

Post by sting sting
I had looked at kernel/fork.c in 2.4.20 (and also 2.6.7) kernel.
In 2.4.20,there is a method named do_fork(); what seems relevant to memory
copying seems to me the call inside to copy_mm() which calls dup_mm().
I had looke at the code of theses methods and could not find a code where
there is a setting to SHARED and READ-ONLY for the pages
of the memory for the new process; any idea?

The mm code is pretty hairy, so it's sometimes hard to track something
like this down. If you go to dup_mmap, which you found in kernel/fork.c,
you'll see that it calls memory.c/copy_page_range. That function
copies a pud (looking at a 2.6.11.6 kernel), which calls down and down
until copy_one_pte is called.

Inside that function, you'll see ptep_set_wrprotect called when the
page is *not* shared. If it's shared, making it COW would un-share
the page!

The ptep_set_wrprotect macro is defined on i386 in
include/asm-i386/pgtable.h like so, turning off the bit that allows
writing:

static inline void ptep_set_wrprotect(pte_t *ptep) \
{ clear_bit(_PAGE_BIT_RW, &ptep->pte_low); }

Post by sting sting
I want to clarify one more thing: I assume that the memory of the old
process which called fork() remains with the same privileges as it was
before calling fork
(Namely , if it was R/W before fork() it will stay R/W also after fork()).

No, if the child had a COW relationship to the page and the parent
didn't, then the parent could write to the page and the child would
see the changes. That's not what happens unless the pages are
shared.

The child effectively gets a snapshot of memory at the time fork was
called.