[haiku-commits] Re: haiku: hrev46463 - src/system/kernel/vm src/system/kernel headers/private/kernel/vm
- From: Ingo Weinhold <ingo_weinhold@xxxxxx>
- To: haiku-commits@xxxxxxxxxxxxx
- Date: Tue, 03 Dec 2013 16:13:59 +0100
On 12/02/2013 03:48 PM, Axel Dörfler wrote:
Can't B_BASE_ADDRESS imply deterministic anyway? I mean what's the point
otherwise?
Given how the randomized version of that algorithm is implemented, there
actually isn't one, i guess.
On 12/02/2013 03:53 PM, Pawel Dziepak wrote:> 2013/12/2 Ingo Weinhold
<ingo_weinhold@xxxxxx>:
>> Something like B_TRY_EXACT_ADDRESS or B_PREFER_EXACT_ADDRESS sounds
good as
>> name in general, but it wouldn't convey the fact that the algorithm
would
>> use the given address as a base address, i.e. return the closest
available
>> address at or after the given address (if any).
>
> But, again, if the algorithm fails to allocate area at the requested
> then why fall back to B_BASE_ADDRESS instead of B_ANY_ADDRESS? I mean,
> if the client code doesn't gets what would be ideal for it then it
> probably doesn't matter if the area is at higher or lower address.
> Actually, I'm not sure we need B_BASE_ADDRESS at all.
I believe the purpose of B_BASE_ADDRESS is to have some means of
managing the address space. So one can e.g. group smaller, equally sized
allocations in one range of the address space without risking to
fragment the address space. I believe that feature is at least useful
for the kernel, maybe in rare cases also for userland programs.
How about the following?
* Drop B_RANDOMIZED_{ANY,BASE}_ADDRESS.
* Introduce B_PREFERRED_ADDRESS. It tries the given address, falling
back to B_ANY_ADDRESS, when unsuccessful.
* Make B_ANY_ADDRESS allocate a randomized address, when ASLR is enabled.
* Keep B_BASE_ADDRESS's (deterministic) behavior. Replace uses where it
isn't needed by B_ANY_ADDRESS or B_PREFERRED_ADDRESS.
CU, Ingo
Other related posts:
