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#>
<#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.