lkml.org 
[lkml]   [2017]   [Jul]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [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.

\
 
 \ /
  Last update: 2017-07-04 02:28    [W:0.170 / U:0.116 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site