On Wed, Jun 14, Vladimir G Ivanovic wrote:
> What is this supposed to do?
Okay, I asked Andrea Arcangeli what this patch from SuSE is used be
for and I got this answer:
JFYI:
----------------------------------------------------------------------
In the VM of a process there is heap and stack. They can be near. (the
heap can just be simple plain anonymous memory)
| GAP |
--------------------------
| heap | | stack |
--------------------------
Y X
Now assume esp is pointing to location X and then a function is recalled
and the function allocate on the stack an array large GAP*PAGE_SIZE plus
some more kbyte just to cause esp to be set to Y.
At this point esp is ponting over the heap and it will corrupt the
heap. None segmentation fault will happen and the heap will be corrupted
silenty. This is what was happening to one application I received and you
can guess this is a pain to debug if you don't have the clue to check
where the esp is writing to.
The official kernel acts exactly like with the patch applied and the
sysctl set to 0. So in the stock kernel none gap of empty virtual space is
enforced between heap and stack. The patch enforces this gap. If somebody
tries in any way to access the memory in the GAP area a segmentation fault
will happen. The GAP is in unit of pages and it's set to 128 by default
(something like 512k).
HotSpot is allocating with MAP_FIXED an alternative stack for the
sighandlers and it's allocating it only a few houndred of kbytes before
the top of the stack (according to the strace it's allocated at address
0xbff7c000). The kernel feature recognize this and segfaults the
application because it's considering too risky to have a so small gap (if
the application would allocate an array of some houndred of kbytes it
would then overlap on the alternatative stack silenty).
Engeneers at Sun acknowledge the goodness of the kernel feature and they
correctly suggested to change the gap from 128 pages to 10 pages to
provide larger flexibility. This should be enough to make the current
HotSpot to work and it will continue to provide additional robusteness to
HotSpot at runtime.
echo 10 >/proc/sys/vm/heap-stack-gap
If you just set the heap-stack-gap to 0 you can left it to zero. In such
case you won't have the additional robusteness provided by the kernel
addition but that is not an issue for all correctly implemented
applications like HotSpot.
Andrea
----------------------------------------------------------------------
--
mit freundlichen Gruessen,
Carsten Hoeger - SuSE Professional Services -
SuSE GmbH, Schanzaeckerstr. 10, 90443 Nuernberg, Germany
Tel: +49-911-7405356 Mo-Fr 09-17.00, Fax: +49-911-3206727
http://www.suse.de/de/support/prof/index.html
----------------------------------------------------------------------
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
