On Tue, Sep 18, 2018 at 3:15 AM, Paul Burton <paul.burton@xxxxxxxx> wrote: > 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? Yes, I use a statically linked binary, so heap expanding is only affected by VDSO, but not by ld.so. However, in the legacy layout case, both VDSO and ld.so are mapped begin with TASK_UNMAPPED_BASE (0x2AAAB000), so a dynamically linked binary's heap will not probablly hit VDSO/ld.so (because dynamically linked binaries are small). > > 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. The task stack is allocated very early, if without changing STACK_TOP, get_unmapped_area() cannot assure that VDSO is above stack. Huacai > > Thanks, > Paul
