On Mon, 15 Oct 2001, Joseph A Knapka wrote: > Sourav Sen wrote: > > > > > Martin Maletinsky wrote: > > > > > > > > Hello Joe, > > > > > > > > Thanks again for your answer. I have one more question regarding a statement you make in your answer: > > > > > > > > Joseph A Knapka wrote: > > > > > > > > > > > > > > In this case, A and B will always share page mappings, even > > > > > when writing to copy-on-write pages, and C will get its own > > > > > copy if/when it attempts to write the page. Here's why: > > > > > > > > > > In do_fork(), we call copy_mm(), which, in the case of > > > > > CLONE_VM being set, just copies the entire mm context > > > > > for the new thread, -without- marking anything copy-on-write. > > > > > So thread A and thread B both have non-COW mappings. > > > > > > > > > > When Thread B forks process C, C gets an entirely new MM > > > > > context, with -no- user-space PTEs. So in order to write > > > > > A+B's virtual page, C takes a "not-present" page fault.regards > > > > > > > > Why is it that C will have no user-space PTEs in it's MM. I thought at a fork call, the user-space PTEs are copied from the parent's MM into the childs MM, and write protected in both > > > > MMs. > > > > I concluded that from the following call sequence (in 2.4.10): > > > > do_fork() > > > > -> copy_mm() > > > > --> dup_mmap() [note that since C is created by a call to fork(), CLONE_VM is *not* set, when creating C] > > > > ---> copy_page_range() [here the PTEs are copied for one vmarea; both PTEs (child and parent) are write protected at line 256, if the conditions to make them COW are fullfilled]. > > > > > > > > My understanding was therefore that all physical pages backing A&B's page mapping would now be shared among A&B and C, and write access to this pages (by either A/B or C would cause a > > > > copy-on-write). > > > > > > > > Did I misunderstand somthing in your answer or in the source code? > > > > > > No, you're right. I didn't read dup_mmap() carefully. Now I don't > > > understand it either :-( > > > > Could you explain the problem here? Now, pages are write > > protected, and B (ie, A+B) writes to the page containing the buffer to > > which A has initiated read(), gets a new physical page to which old > > contents are copied and old virtual address of the buffer(in A+B address > > space)are mapped, read() resumes and copy_to_user() copies the remaining > > data to this new page, and read() completes normally with the buffer > > filled with data. > > The problem comes if the device is doing a DMA write > directly to the user page. In that case doing COW will > cause the DMA buffer to mysteriously vanish, from the > point of view of the thread that initiated the write. > > I am taking Martin's word that it's actually possible > to do DMA in this way (directly to a user page, bypassing > kernel buffers and copy-to-user). If all I/O > passes through kernelspace buffers, then there > is no problem. I have not studied the I/O system in > much detail. Upon further though, though, I think > DMA to user pages is probably -not- done, because AFAIK, its correct, its not done save some research systems like U-net (though that is in the network side, not disk) but there I think these issues are taken care of differently. regards sourav - Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ IRC Channel: irc.openprojects.net / #kernelnewbies Web Page: http://www.kernelnewbies.org/
