Messages in this thread | | | From | Andy Lutomirski <> | Date | Mon, 3 Jul 2017 17:27:50 -0700 | Subject | Re: [PATCH] mm: larger stack guard gap, between vmas |
| |
On Mon, Jul 3, 2017 at 4:55 PM, Ben Hutchings <ben@decadent.org.uk> wrote: > On Wed, 2017-06-21 at 11:47 +0100, Ben Hutchings wrote: >> On Wed, 2017-06-21 at 11:24 +0200, Michal Hocko wrote: >> > On Wed 21-06-17 02:38:21, Ben Hutchings wrote: >> > > On Mon, 2017-06-19 at 16:23 +0200, Willy Tarreau wrote: >> > > > On Mon, Jun 19, 2017 at 08:44:24PM +0800, Linus Torvalds wrote: >> > > > > The distros are in a different situation and don't have that >> > > > > two-week >> > > > > window until a release, and presumably would not want to cut >> > > > > over to >> > > > > something new and fairly untested on such short notice. >> > > > > >> > > > > The timing for this all sucks, but if somebody has some final >> > > > > comments, please speak up now.. >> > > > >> > > > What do you suggest the stable maintainers do here ? I've just >> > > > backported >> > > > this patch back to 3.10 and could boot it on i386 where it >> > > > apparently >> > > > works. But we may need more tests. On the other hand we benefit >> > > > from the >> > > > automated tests on tens of platforms when we push the queues so >> > > > at least >> > > > we'll quickly know if it builds and boots. I just don't feel >> > > > confident in >> > > > my work just because it builds and boots, you know. >> > > > >> > > > I'm appending the patches I currently have if anyone wants to >> > > > have a >> > > > glance. Ben, 3.2 requires much more changes than 3.10 and I'm >> > > > pretty >> > > > sure you won't change your patches at the last minute so I gave >> > > > up. >> > > >> > > Well I'm now dealing with fall-out from the Debian stable updates, >> > > which used a backport of Michal's patch series. That unfortunately >> > > seems to break programs running Java code in the main thread (the >> > > 'java' command doesn't do this, but e.g. 'jsvc' does). >> > >> > Could you share more details please? >> >> https://bugs.debian.org/865303 >> https://bugs.debian.org/865311 >> https://bugs.debian.org/865343 > > Unfortunately these regressions have not been completely fixed by > switching to Hugh's fix. > > 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?
That change makes sense to me.
| |