Date: Tue, 4 Jul 2017 21:03:00 +0200
From: Willy Tarreau <w@1wt.eu>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Michal Hocko <mhocko@kernel.org>, Ben Hutchings <ben@decadent.org.uk>,
        Hugh Dickins <hughd@google.com>, 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>, Ximin Luo <infinity0@debian.org>
Subject: Re: [PATCH] mm: larger stack guard gap, between vmas
Message-ID: <20170704190300.GJ22013@1wt.eu>
References: <20170704084122.GC14722@dhcp22.suse.cz>
 <20170704093538.GF14722@dhcp22.suse.cz>
 <20170704094728.GB22013@1wt.eu>
 <20170704104211.GG14722@dhcp22.suse.cz>
 <20170704113611.GA4732@decadent.org.uk>
 <20170704155140.GC22013@1wt.eu>
 <20170704172247.GA6178@dhcp22.suse.cz>
 <CA+55aFyAunJqeoZfcOFjPS3ZQvm_zM2xztvwxkcJ5fhk1Xzmqw@mail.gmail.com>
 <20170704183927.GH22013@1wt.eu>
 <CA+55aFyjihU+73h07a4XwUdgZixk=EhU5yQFjaii4sbcymT2tQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CA+55aFyjihU+73h07a4XwUdgZixk=EhU5yQFjaii4sbcymT2tQ@mail.gmail.com>
User-Agent: Mutt/1.6.1 (2016-04-27)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 852
Lines: 21

On Tue, Jul 04, 2017 at 11:47:37AM -0700, Linus Torvalds wrote:
> Let's
> say that you are using lots of threads, so that you know your stack
> space is limited. What you do is to use MAP_FIXED a lot, and you lay
> out your stacks fairly densely (with each other, but also possibly
> with other mappings), with that PROT_NONE redzoning mapping in between
> the "dense" allocations.
> 
> So when the kernel wants to grow the stack, it finds the PROT_NONE
> redzone mapping - but there's possibly other maps right under it, so
> the stack_guard_gap still hits other mappings.
(...)

OK I didn't get that use case, that totally makes sense indeed! So
now we use PROT_NONE not as something that must be skipped to find
the unmapped area but as a hint that the application apparently
wants the stack to stop here.

Thanks for this clear explanation!

Willy