Messages in this thread | | | Date | Tue, 4 Jul 2017 10:41:22 +0200 | From | Michal Hocko <> | Subject | Re: [PATCH] mm: larger stack guard gap, between vmas |
| |
On Mon 03-07-17 17:05:27, Linus Torvalds wrote: > On Mon, Jul 3, 2017 at 4:55 PM, Ben Hutchings <ben@decadent.org.uk> wrote: > > > > Firstly, some Rust programs are crashing on ppc64el with 64 KiB pages. > > Apparently Rust maps its own guard page at the lower limit of the stack > > (determined using pthread_getattr_np() and pthread_attr_getstack()). I > > don't think this ever actually worked for the main thread stack, but it > > now also blocks expansion as the default stack size of 8 MiB is smaller > > than the stack gap of 16 MiB. Would it make sense to skip over > > PROT_NONE mappings when checking whether it's safe to expand?
This is what my workaround for the older patch was doing, actually. We have deployed that as a follow up fix on our older code bases. And this has fixed verious issues with Java which was doing the similar thing.
> Hmm. Maybe. > > Also, the whole notion that the gap should be relative to the page > size never made sense to me. So I think we could/should just make the > default gap size be one megabyte, not that "256 pages" abortion.
The reason for having this in page units was that MAX_ARG_STRLEN is in page units as well. And this is used as an on stack variable quite often. 1MB wouldn't be sufficient for that to cover - we could go with a larger gap but who knows how many other traps are there.
> > Secondly, LibreOffice is crashing on i386 when running components > > implemented in Java. I don't have a diagnosis for this yet. > > Ugh. Nobody seeing this inside SuSe/Red Hat? I don't think I've heard > about this..
No reports yet but we do not support 32b kernels on newer kernels which had the upstream fix.
-- Michal Hocko SUSE Labs
| |