Re: heap-stack-gap for 2.6

[Hui Huang]

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/