2010/2/3 Owain Ainsworth <zerooa@googlemail.com>:
quoted text
> ...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 <ariane@stack.nl>:
quoted text
> 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.
...
quoted text
> 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