On Thu, 10 Oct 2002, Martin Maletinsky wrote: > > While studying the follow_page() function (the version of the function > that is in place since 2.4.4, i.e. with the write argument), I noticed, > that for an address that > should be written to (i.e. write != 0), the > function checks not only the writeable flag (with pte_write()), but also > the dirty flag (with pte_dirty()) of the page > containing this address. > From what I thought to understand from general paging theory, the dirty > flag of a page is set, when its content in physical memory differs from > its backing on the permanent storage system (file or swap space). Based > on this understanding I do not understand why it is necessary to check > the dirty flag, in order to ensure that a page is writable > - what am I missing here? Good question (and I don't see the answer in Dharmender's replies). I expect Stephen can give the definitive answer, but here's my guess. follow_page() was introduced for kiobufs, so despite its general name, it's doing what map_user_kiobuf() needed (or thought it needed). Originally (pre-2.4.4), as you've noticed, there was no write argument to follow_page, and map_user_kiobuf made one call to handle_mm_fault per page. Experience with races under memory pressure will have shown that to be inadequate, it needed to loop until it could hold down the page, with the writable bit in the pte guaranteeing it good to write to. But why dirty too, you ask? I think, because writing to page via kiobuf happens directly, not via pte, so the pte dirty bit would not be set that way; but if it's not set, then the modification to the page may be lost later. Hence map_user_kiobuf used handle_mm_fault to set that dirty bit too, and used follow_page to check that it is set. Except that's racy too, and so mark_dirty_kiobuf() was added to SetPageDirty on the pages after kio done, before unmapping the kiobuf. mark_dirty_kiobuf appeared in the main kernel tree at the same time as the pte_dirty test in follow_page, but I'm guessing the pte_dirty test was an earlier failed attempt to solve the problems fixed by mark_dirty_kiobuf, which got left in place (and also helped a bit if kiobuf users weren't updated to call mark_dirty_kiobuf). Apologies in advance if my guesses are wild. Hugh -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
