Re: Meaning of the dirty bit

 --- Hugh Dickins [off-list ref] wrote: > On Thu,
10 Oct 2002, Martin Maletinsky wrote:

quoted

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

quoted

that is in place since 2.4.4, i.e. with the write

argument), I noticed,

quoted

that for an address that > should be written to

(i.e. write != 0), the

quoted

function checks not only the writeable flag (with

pte_write()), but also

quoted

the dirty flag (with pte_dirty()) of the page >

containing this address.

quoted

From what I thought to understand from general

paging theory, the dirty

quoted

flag of a page is set, when its content in

physical memory differs from

quoted

its backing on the permanent storage system (file

or swap space). Based

quoted

on this understanding I do not understand why it

is necessary to check

quoted

the dirty flag, in order to ensure that a page is

writable

quoted

- 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
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/