From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755117AbdFWUfy (ORCPT ); Fri, 23 Jun 2017 16:35:54 -0400 Received: from mx2.suse.de ([195.135.220.15]:37204 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1754971AbdFWUfx (ORCPT ); Fri, 23 Jun 2017 16:35:53 -0400 Date: Fri, 23 Jun 2017 22:35:50 +0200 (CEST) From: Jiri Kosina X-X-Sender: jkosina@pobox.suse.cz To: Linus Torvalds , mingo@kernel.org, Michal Hocko , hpa@zytor.com, oleg@redhat.com, Thomas Gleixner , davej@codemonkey.org.uk, peterz@infradead.org, linux-kernel@vger.kernel.org cc: linux-tip-commits@vger.kernel.org Subject: Re: [tip:x86/mm] x86/mmap, ASLR: Do not treat unlimited-stack tasks as legacy mmap In-Reply-To: Message-ID: References: <20170614082218.12450-1-mhocko@kernel.org> User-Agent: Alpine 2.20 (LSU 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 23 Jun 2017, tip-bot for Michal Hocko wrote: > TASK_SIZE (allowed by mmap_base) is pretty much unimited in the real > life. This would give mmap 20TB of additional address space which is > quite nice. Especially when it is much more likely to use that address > space than the reserved stack. > > Digging into the history the original implementation of the randomization: > > 8817210d4d96 ("[PATCH] x86_64: Flexmap for 32bit and randomized mappings for 64bit") > > didn't have this restriction. > > So let's try and remove this assumption - hopefully nothing breaks. > > Signed-off-by: Michal Hocko > Cc: Dave Jones > Cc: Jiri Kosina > Cc: Linus Torvalds > Cc: Oleg Nesterov > Cc: Peter Zijlstra > Cc: Thomas Gleixner > Cc: akpm@linux-foundation.org > Cc: hughd@google.com > Cc: linux-mm@kvack.org > Cc: will.deacon@arm.com > Link: http://lkml.kernel.org/r/20170614082218.12450-1-mhocko@kernel.org > [ So I've applied this to tip:x86/mm with a wider Cc: list - if anyone objects to this change please holler. ] > Signed-off-by: Ingo Molnar > --- > arch/x86/mm/mmap.c | 3 --- > 1 file changed, 3 deletions(-) > > diff --git a/arch/x86/mm/mmap.c b/arch/x86/mm/mmap.c > index 19ad095..797295e 100644 > --- a/arch/x86/mm/mmap.c > +++ b/arch/x86/mm/mmap.c > @@ -74,9 +74,6 @@ static int mmap_is_legacy(void) > if (current->personality & ADDR_COMPAT_LAYOUT) > return 1; > > - if (rlimit(RLIMIT_STACK) == RLIM_INFINITY) > - return 1; > - >>From the person who actually added this particular restriction Acked-by: Jiri Kosina I think it was some historical remnant from the times when 32/64 arch code split still existed, but can't really recall any details after all those years; it doesn't make sense to me any more. Thanks, -- Jiri Kosina SUSE Labs