Hi Huacai,
On Sat, Sep 15, 2018 at 01:51:30PM +0800, Huacai Chen wrote:
> Unlimited stack size (ulimit -s unlimited) causes kernel to use legacy
> layout for applications. Thus, if VDSO isn't mapped above STACK_TOP, it
> will be mapped at a very low address. This will probably cause an early
> brk() failure, because the application's initial mm->brk is usually
> below VDSO (especially when COMPAT_BRK is enabled) and there is no more
> room to expand its heap.
>
> This patch reserve 4 MB space above STACK_TOP, and use the low 2 MB for
> VDSO randomization (as a result, VDSO pages can use as much as 2 MB).
>
> Signed-off-by: Huacai Chen <chenhc@xxxxxxxxxx>
> ---
> arch/mips/include/asm/processor.h | 5 +++--
> arch/mips/kernel/vdso.c | 16 +++++++++++++++-
> 2 files changed, 18 insertions(+), 3 deletions(-)
Could you give an example of a program that fails due to this?
I'm able to reproduce that with ulimit -s unlimited the VDSO gets placed
just above the heap, but the ELF interpreter & shared libraries get
mapped nearby too so even with the VDSO moved a brk syscall would still
presumably fail at around the same point. For example:
# ulimit -s unlimited; cat /proc/self/maps
00400000-004ec000 r-xp 00000000 08:00 71436 /usr/bin/coreutils
004fc000-004fd000 rwxp 000ec000 08:00 71436 /usr/bin/coreutils
004fd000-0050f000 rwxp 00000000 00:00 0
00cc3000-00ce4000 rwxp 00000000 00:00 0 [heap]
2ab75000-2ab96000 r-xp 00000000 08:00 44641 /lib/ld-linux-mipsn8.so.1
2ab96000-2ab98000 r--p 00000000 00:00 0 [vvar]
2ab98000-2ab99000 r-xp 00000000 00:00 0 [vdso]
2ab99000-2ab9d000 rwxp 00000000 00:00 0
2aba5000-2aba6000 r-xp 00020000 08:00 44641 /lib/ld-linux-mipsn8.so.1
2aba6000-2aba7000 rwxp 00021000 08:00 44641 /lib/ld-linux-mipsn8.so.1
2aba7000-2ad18000 r-xp 00000000 08:00 477163 /usr/lib/libcrypto.so.1.0.0
2ad18000-2ad27000 ---p 00171000 08:00 477163 /usr/lib/libcrypto.so.1.0.0
...
Are you running something statically linked to avoid that?
Apart from that I'm not keen on unconditionally taking away 4MB of
address space. For o32 programs we already only have 2GB of user address
space & it's not unheard of for programs to bump up against that limit,
so reducing it further would need to be a last resort. If we did need to
move VDSO to the top of the user address space we can do that with a
hint to get_unmapped_area() without changing STACK_TOP.
Thanks,
Paul
