On Tue, Feb 26, 2013 at 4:57 AM, Heiko Carstens
<heiko.carst...@de.ibm.com> wrote:
>
> I was wrong. -EFAULT will be returned, however the vma will grow nevertheless.
> Which in turn will cause trouble.
Ok. We should fix that too.
There whole "access just past the end of the previous vma" should
never cause the stack above to expand. The guard page at least gives
people a SIGSEGV, but one of the main reasons for the guard page was
actually to make sure that new "mmap()" calls do not create mappings
just under the stack (in addition to the obvious SIGSEGV when you then
access into that thing).
So while part of the meaning of the guard page is to get that SIGSEGV,
that part is "for safetly". And apparently it works. But at the same
time, there is absolutely no reason to ever expand the stack only to
hit the guard page _anyway_, so if the stack expansion will cause the
requested address to be in the guard page, then the stack expansion
should just have failed.
I think the problem is that we add the guard page *after* we do the
normal "let's try to expand" logic.
I'll take a look.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
