Re: heap-stack-gap for 2.6

[Hui Huang <Hui.Huang@Sun.COM>]

Andrea Arcangeli wrote:
> 
>>Now another wish - instead of a system-wide property, a per-process
>>mechanism to change heap-stack-gap. Applications that need the gap
>>can set up the appropriate size, while others like Java that manage
>>heap and stack can simply disable the gap. Is it possible?
> 
> 
> This is a very reasonable request, and yes, this is definitely possible,
> I feel this is a much better feature than the mprotect trapping, which
> is possible too, but it sounds not worth it.
> 
> As for the api, should that be a prctl, /proc/<pid>/heap-stack-gap, or a
> brand new syscall? I personally enjoy the /proc/<pid>/heap-stack-gap
> approach, but that's just me, the prctl and syscall would be more
> efficient at runtime (but the point is that this doesn't need to be more
> efficient and echo xx > /proc/<pid>/heap-stack-gap is so much easier to
> play with for experiments)

Hi Andrea,

 From our perspective prctl is the most attractive approach. Performance
is not an issue, as it's only used once during startup. The problem
with /proc is that we are not always able to access /proc (e.g.
java code is run with chroot). Stack overflow in chroot'ed program
probably is a corner case, but I'm afraid we'll have to deal with it
if the heap-stack-gap becomes more widespread. System call is better
but we need to remember different syscall numbers on different
platforms.

> 
> If we can choose the API together I'll take care of implementing the
> rest. I'd like to still leave a global sysctl for global system safety
> (since most apps needs it and they won't all be required to tune it by
> hand), so that the final number will be choose with:
> 
> 	if (likely(per_process_setting < 0))
> 		return global_sysctl;
> 	else
> 		return per_process_setting;


Sounds good.

thanks,
-hui