Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751979AbdGDA2O (ORCPT ); Mon, 3 Jul 2017 20:28:14 -0400 Received: from mail.kernel.org ([198.145.29.99]:40028 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750835AbdGDA2N (ORCPT ); Mon, 3 Jul 2017 20:28:13 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 273A022C96 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=luto@kernel.org MIME-Version: 1.0 In-Reply-To: <1499126133.2707.20.camel@decadent.org.uk> References: <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: Andy Lutomirski Date: Mon, 3 Jul 2017 17:27:50 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] mm: larger stack guard gap, between vmas To: Ben Hutchings Cc: Michal Hocko , Hugh Dickins , Willy Tarreau , Linus Torvalds , Oleg Nesterov , "Jason A. Donenfeld" , Rik van Riel , Larry Woodman , "Kirill A. Shutemov" , Tony Luck , "James E.J. Bottomley" , Helge Diller , James Hogan , Laura Abbott , Greg KH , "security@kernel.org" , linux-distros@vs.openwall.org, Qualys Security Advisory , LKML Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2622 Lines: 57 On Mon, Jul 3, 2017 at 4:55 PM, Ben Hutchings 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.