Re: [PATCH] mm: larger stack guard gap, between vmas

From: Ben Hutchings
Date: Tue Jul 04 2017 - 19:03:01 EST


On Tue, 2017-07-04 at 12:36 +0100, Ben Hutchings wrote:
[...]
> This *doesn't* fix the LibreOffice regression on i386.

gdb shows me that the crash is at the last statement in this function:

static void _expand_stack_to(address bottom) {
 address sp;
 size_t size;
 volatile char *p;

 // Adjust bottom to point to the largest address within the same page, it
 // gives us a one-page buffer if alloca() allocates slightly more memory.
 bottom = (address)align_size_down((uintptr_t)bottom, os::Linux::page_size());
 bottom += os::Linux::page_size() - 1;

 // sp might be slightly above current stack pointer; if that's the case, we
 // will alloca() a little more space than necessary, which is OK. Don't use
 // os::current_stack_pointer(), as its result can be slightly below current
 // stack pointer, causing us to not alloca enough to reach "bottom".
 sp = (address)&sp;

 if (sp > bottom) {
ÂÂÂÂsize = sp - bottom;
ÂÂÂÂp = (volatile char *)alloca(size);
ÂÂÂÂassert(p != NULL && p <= (volatile char *)bottom, "alloca problem?");
ÂÂÂÂp[0] = '\0';
 }
}

We have:

bottom = 0xff803fff
sp = 0xffffb178

The relevant mappings are:

ff7fc000-ff7fd000 rwxp 00000000 00:00 0
fffdd000-ffffe000 rw-p 00000000 00:00 0ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ[stack]

So instead of a useless guard page, we have a dangerous WX page
underneath the stack! I suppose I should find out where and why that's
being allocated.

Ben.

--
Ben Hutchings
The world is coming to an end. Please log off.

Attachment: signature.asc
Description: This is a digitally signed message part