"sting sting" <zstingx@xxxxxxxxxxx> writes:
> 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.
> 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); }
> 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.
--
Ed L Cashin <ecashin@xxxxxxxxxx>
--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive: http://mail.nl.linux.org/kernelnewbies/
FAQ: http://kernelnewbies.org/faq/
