Messages in this thread | | | Date | Tue, 4 Jul 2017 12:46:52 +0200 | From | Michal Hocko <> | Subject | Re: [PATCH] mm: larger stack guard gap, between vmas |
| |
On Tue 04-07-17 11:35:38, Michal Hocko wrote: > On Tue 04-07-17 10:41:22, Michal Hocko wrote: > > 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. > > Here is a forward port (on top of the current Linus tree) of my earlier > patch. I have dropped a note about java stack trace because this would > most likely be not the case with the Hugh's patch. The problem is the > same in principle though. Note I didn't get to test this properly yet > but it should be pretty much obvious.
Tested with the attached program. root@test1:~# ./stack_crash Stack top:0x7fffcdb605ec mmap:0x7fffcc760000 address:0x7fffcc760ff8 aligned:0x7fffcc760000 mapped:[7fffcc760000,7fffcc761000] diff:-8 [...]
so we faulted on the PROT_NONE while with #define MAPING_PROT PROT_READ root@test1:~# ./stack_crash Stack top:0x7ffe73dde6fc mmap:0x7ffe729de000 address:0x7ffe72adefd8 aligned:0x7ffe72ade000 mapped:[7ffe729de000,7ffe729df000] diff:1048536 [...]
we failed 1MB ahead of the mapping. -- Michal Hocko SUSE Labs
| |