Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752129AbdGERZH (ORCPT ); Wed, 5 Jul 2017 13:25:07 -0400 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:58350 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751692AbdGERZF (ORCPT ); Wed, 5 Jul 2017 13:25:05 -0400 Message-ID: <1499275472.2707.44.camel@decadent.org.uk> Subject: Re: [PATCH] mm: larger stack guard gap, between vmas From: Ben Hutchings To: Michal Hocko Cc: Linus Torvalds , Willy Tarreau , Hugh Dickins , 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" , Qualys Security Advisory , LKML , Ximin Luo Date: Wed, 05 Jul 2017 18:24:32 +0100 In-Reply-To: <20170705170552.GA13487@dhcp22.suse.cz> References: <20170704093538.GF14722@dhcp22.suse.cz> <20170704094728.GB22013@1wt.eu> <20170704104211.GG14722@dhcp22.suse.cz> <20170704113611.GA4732@decadent.org.uk> <1499209315.2707.29.camel@decadent.org.uk> <1499257180.2707.34.camel@decadent.org.uk> <20170705142354.GB21220@dhcp22.suse.cz> <1499268300.2707.41.camel@decadent.org.uk> <20170705165845.GB4732@decadent.org.uk> <20170705170552.GA13487@dhcp22.suse.cz> Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-ViU1GX1vcL132hzglRDU" X-Mailer: Evolution 3.22.6-1 Mime-Version: 1.0 X-SA-Exim-Connect-IP: 82.70.136.246 X-SA-Exim-Mail-From: ben@decadent.org.uk X-SA-Exim-Scanned: No (on shadbolt.decadent.org.uk); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2754 Lines: 76 --=-ViU1GX1vcL132hzglRDU Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 2017-07-05 at 19:05 +0200, Michal Hocko wrote: > On Wed 05-07-17 17:58:45, Ben Hutchings wrote: > [...] > > diff --git a/mm/mmap.c b/mm/mmap.c > > index c7906ae1a7a1..f8131a94e56e 100644 > > --- a/mm/mmap.c > > +++ b/mm/mmap.c > > @@ -2307,6 +2307,25 @@ int expand_upwards(struct vm_area_struct *vma, u= nsigned long address) > > =C2=A0} > > =C2=A0#endif /* CONFIG_STACK_GROWSUP || CONFIG_IA64 */ > > =C2=A0 > > +unsigned long __vm_start_gap(struct vm_area_struct *vma) > > +{ > > + unsigned long stack_limit =3D > > + current->signal->rlim[RLIMIT_STACK].rlim_cur; > > + unsigned long vm_start; > > + > > + if (stack_limit !=3D RLIM_INFINITY && > > + =C2=A0=C2=A0=C2=A0=C2=A0vma->vm_end - vma->vm_start < stack_limit) > > + vm_start =3D vma->vm_end - PAGE_ALIGN(stack_limit); >=20 > This is exactly what I was worried about in my previous email. Say > somebody sets stack ulimit to 1G or so. Should we reduce the available > address space that much? It's not ideal, but why would someone set the stack limit that high unless it's for an application that will actually use most of that stack space? Do you think that "increase the stack limit" has been cargo-culted? > Say you are 32b and you have an application > with multiple stacks each doing its MAP_GROWSDOWN. [...] So this application is using dietlibc or uclibc? glibc uses fixed-size=20 mappings for new threads. I suppose there's a risk that by doing this we would mamke MAP_GROWSDOWN useful enough that it is more likely to be used for new thread stacks in future. Ben. --=20 Ben Hutchings Anthony's Law of Force: Don't force it, get a larger hammer. --=-ViU1GX1vcL132hzglRDU Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEErCspvTSmr92z9o8157/I7JWGEQkFAlldINAACgkQ57/I7JWG EQk4ChAAoo6K0/OdUQ2atCOgDB88WoEJyuxVcCKaVh4N/5WKtvMa43bobzrr5ltN NdEg2ouLAoRAZMPSG27BoZQas85kPk1WZRj1nCp+8zgwdckXeZfqKXXINXl0Ym0Z wj5YbLCWJrAl7bh6ysVQJplN4uq8rFid2OHCHW7d9m/8CPDgDkBkaVhqbzZFpAQT 4dOD7f5Am7d4p2+xFoSYxa+jFTKxHfqH4Xz/0pNqdYRviVJRnr2A5ukPoBkgU5Pw hgzTL/58Uclz9Oge2cy8crg5gnC0qDo/iyq42qKjHxsFIYpJ3izq/0c87WdrmvoQ BRvXZxFFNtNb7i7UkIHKdwdbEgQdrUfWC697UCVnQvXvFq7/HELBZMwROYFy+hM3 1WiQ4dYfMdORt4YkHaJ1U41YT8Thj8ISAx/FMS5uUhUH0TdnP5XZD6Zwg+kesOSh bj7muTpkD9yRs2MNAdWc22Bi9Lr+CKwiRyVWJOJ4qdtQpHcO0H2d482rjripDNho TA41hDYtkNqKVfrFULYswf9+/faNKTPm1veT3qslrm6rpChOwv1DYZeKpxNwZgQ4 YHaPU2oOsFmpgPoLSVHNi1D9jite2nulZQn7xvlpJRefCeR5XFUbh1YGAB3WU8R/ pS/aKYHxA3cKaFrfkdFfP83HyRsRmauS3vm08Xko6PErPKii1tE= =uFpw -----END PGP SIGNATURE----- --=-ViU1GX1vcL132hzglRDU--