--- Hugh Dickins <hugh@veritas.com> wrote: > On Thu, 10 Oct 2002, Martin Maletinsky wrote: > > > > While studying the follow_page() function (the > version of the function Hugh, Here is the link to know more about follow_page(). I had replied after reading it. http://lwn.net/Articles/11483/ Regards Dharmender Rai > > 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/ > __________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
