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

Ben Hutchings
2017-07-04T23:02:46Z

[-- Attachment #1: Type: text/plain, Size: 1610 bytes --]

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 #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]