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 <mhocko@xxxxxxxx>
> Cc: Dave Jones <davej@xxxxxxxxxxxxxxxxx>
> Cc: Jiri Kosina <jkosina@xxxxxxx>
> Cc: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
> Cc: Oleg Nesterov <oleg@xxxxxxxxxx>
> Cc: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
> Cc: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
> Cc: akpm@xxxxxxxxxxxxxxxxxxxx
> Cc: hughd@xxxxxxxxxx
> Cc: linux-mm@xxxxxxxxx
> Cc: will.deacon@xxxxxxx
> Link: http://lkml.kernel.org/r/20170614082218.12450-1-mhocko@xxxxxxxxxx
> [ 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 <mingo@xxxxxxxxxx>
> ---
> 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 <jkosina@xxxxxxx>
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
--
To unsubscribe from this list: send the line "unsubscribe linux-tip-commits" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
|