2010/2/3 Owain Ainsworth <[email protected]>: > ...you can't just go straight to the start of the map. > Say i386 where W^X is done using segments. if you dump > something right at the other end of the segment, that pretty much screws > it. Perhaps going back to the min hint for the protection and trying to > push just a little bit down may work?
2010/2/4 Ariane van der Steldt <[email protected]>: > mmap(..., MAP_FIXED) requires a search by addr. > uvm_map_findspace() should also be able to take an addr constraint: > like Oga said, i386 has a segmented view of memory wrt W^X. ... > One more problem you may face, is uvm_km_getpage starvation. If it > happens, you'll be unable to allocate a vm_map_entry. In your design, > you'll need 2 per allocation most of the time. If that's too much > pressure, the kernel may starve itself and be unable to create new > entries, becoming completely jammed. This is a problem on any > non-pmap_direct architectures (like i386). I remember about MAP_FIXED, just not mentioned it in my not-so-short message ;) And I don't want 2 vm_map_entry per allocation, I only need to keep each vm_map_entry in both trees. One vm_map_entry can contain 2 separate RB_TREE entries (for both trees), so each tree can work with that vm_map_entry independantly. Can anyone explain me what is the problem with i386 segments? Or better supply some links to docs which explain it. I don't understand what you mean - MAP_FIXED flag is the problem or it used as workaround for some problem? -- antonvm
