Subject: Re: [vs-plain] Re: [PATCH] mm: larger stack guard gap, between vmas
To: Ben Hutchings <ben@decadent.org.uk>, Michal Hocko <mhocko@kernel.org>,
        Hugh Dickins <hughd@google.com>
Cc: Willy Tarreau <w@1wt.eu>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Oleg Nesterov <oleg@redhat.com>,
        "Jason A. Donenfeld" <Jason@zx2c4.com>, Rik van Riel <riel@redhat.com>,
        Larry Woodman <lwoodman@redhat.com>,
        "Kirill A. Shutemov" <kirill@shutemov.name>,
        Tony Luck <tony.luck@intel.com>,
        "James E.J. Bottomley" <jejb@parisc-linux.org>,
        Helge Diller <deller@gmx.de>, James Hogan <james.hogan@imgtec.com>,
        Laura Abbott <labbott@redhat.com>, Greg KH <greg@kroah.com>,
        "security@kernel.org" <security@kernel.org>,
        linux-distros@vs.openwall.org,
        Qualys Security Advisory <qsa@qualys.com>,
        LKML <linux-kernel@vger.kernel.org>
References: <alpine.LSU.2.11.1706190355140.2626@eggly.anvils>
 <CA+55aFx6j4na3BVRC2aQuf-kNp1jzGahN8To_SFpNu+H=gopJA@mail.gmail.com>
 <20170619142358.GA32654@1wt.eu> <1498009101.2655.6.camel@decadent.org.uk>
 <20170621092419.GA22051@dhcp22.suse.cz>
 <1498042057.2655.8.camel@decadent.org.uk>
 <1499126133.2707.20.camel@decadent.org.uk>
From: John Haxby <john.haxby@oracle.com>
Message-ID: <c6923749-4db1-2bda-5750-07cd35cedfc2@oracle.com>
Date: Tue, 4 Jul 2017 13:26:15 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <1499126133.2707.20.camel@decadent.org.uk>
Content-Type: text/plain; charset=utf-8
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 973
Lines: 21

On 04/07/17 00:55, Ben Hutchings wrote:
> 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?
> 
> Secondly, LibreOffice is crashing on i386 when running components
> implemented in Java.  I don't have a diagnosis for this yet.

We found that we needed f4cb767d76cf ("mm: fix new crash in
unmapped_area_topdown()")   Apologies if you've already covered that.

This may be needed in addition to the other patch you proposed.

jch