<div dir="ltr">ok, <div><br></div><div>I am sorry maybe I did not ask the question correctly, all I want to know is how mmap works underneath, given an address X how does kernel figure out its a mmaped page ?</div><div><br>
</div><div>-Neo</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jul 25, 2013 at 10:04 AM, <span dir="ltr"><<a href="mailto:Valdis.Kletnieks@vt.edu" target="_blank">Valdis.Kletnieks@vt.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Thu, 25 Jul 2013 09:14:03 -0700, kernel neophyte said:<br>
<br>
> Could anyone please explain, how mmap works underneath ? when kernel<br>
> traveses pgd->pud->pmd->pte how does it know that a particular page is a<br>
> mmaped page ? is there any special flag ?<br>
<br>
</div></div>Why would the address mapping hardware even *care* that it's an mmap'ed<br>
page, once the mapping is set up? For that matter, why would most of<br>
the kernel code care?<br>
<br>
Only time an mmap'ed page is any different than any other process page is<br>
while the mmap is actually being set up, modified, or torn down.<br>
<br>
(And in fact, that's part of why getting the varions sync() calls to play<br>
nice with mmap() is so hard - because an mmap'ed file page is just a page.<br>
So noticing that a page got modified and knowing to do stuff like update<br>
the atime and mtime of the backing file is difficult...)<br>
<br>
</blockquote></div><br></div>