stack size limit on ppc/ppc64

[Benjamin Herrenschmidt]

On Wed, 2003-11-05 at 13:24, Anton Blanchard wrote:
> Hi Anil,
>
> > I have code which shouldn't work, working under ppc64 linux.
>
> Sounds like a feature to me :)
>
> > Theoretically, above code should cause segmentation violation. But on ppc64
> > linux, it puts variable 'p ' in stack segment, I looked at /proc/pid/maps,
> > and there was huge memory area from 0x50000000 ---> 0xFFFFF000.
>
> I guess technically its a bug, Paul has fixed it in ppc32. I attached
> the relevant parts of his fix (it comes from arch/ppc/kernel/fault.c)

It is a bug and not for the reason you may think ;) I fixed it
in ppc32 a while by simply preventing reads from growing the
stack, paulus further improved my fix by doing the writes case
with the insn checking.

The reason why this "feature" can really bite you is things like
sys_mount() which will blindly copy_from_user a whole page
starting at the pointer you pass for the arguments, whatever
the actual string length is. If that string you pass happens
to be near the top of your highest non-stack VMA, the kernel will
happily fault in the byte next to that limit within the
copy_from_user and so grow down your stack all the way down to
your heap, effectively preventing any further memory allocations.

This has caused me plenty of random mount() failures, on embedded
platforms typically, using small sized mount() implementations or
things llike busybox.

Ben.


** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/