A user process' view of memory

#tabular1916#

Both the code segment and data segment extend all the way from 0x00 to 3~GB. Currently the page fault handler <#1922#> do_wp_page<#1922#> checks to ensure that a process does not write to its code space. However, by catching the <#1923#> SEGV<#1923#> signal, it is possible to write to code space, causing a copy-on-write to occur. The handler <#1924#> do_no_page<#1924#> ensures that any new pages the process acquires belong to either the executable, a shared library, the stack, or lie within the <#1925#> brk<#1925#> value. A user process can reset its <#1926#> brk<#1926#> value by calling <#1927#> sbrk()<#1927#>. This is what <#1928#> malloc()<#1928#> does when it needs to. The text and data portions are allocated on separate pages unless one chooses the <#1929#> -N<#1929#> compiler option. Shared library load addresses are currently taken from the shared image itself. The address is between 1.5 GB and 3 GB, except in special cases. <#1930#> User process Memory Allocation<#1930#>

#tabular1931#

<#1940#> [What do the question marks mean? Do they mean that they might go either way, or that you are not sure?]<#1940#> The stack, shlibs and data are too far removed from each other to be spanned by one page table. All kernel <#1941#> page_table<#1941#>s are shared by all processes so they are not in the list. Only dirty pages are swapped. Clean pages are stolen so the process can read them back in from the executable if it likes. Mostly only clean pages are shared. A dirty page ends up shared across a fork until the parent or child chooses to write to it again.