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 <mho...@suse.com> > Cc: Dave Jones <da...@codemonkey.org.uk> > Cc: Jiri Kosina <jkos...@suse.cz> > Cc: Linus Torvalds <torva...@linux-foundation.org> > Cc: Oleg Nesterov <o...@redhat.com> > Cc: Peter Zijlstra <pet...@infradead.org> > Cc: Thomas Gleixner <t...@linutronix.de> > Cc: a...@linux-foundation.org > Cc: hu...@google.com > Cc: linux...@kvack.org > Cc: will.dea...@arm.com > Link: http://lkml.kernel.org/r/20170614082218.12450-1-mho...@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 <mi...@kernel.org> > --- > 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 <jkos...@suse.cz> 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