From 45c6c04d8db529cb9b5d534e747318aac5f9334f Mon Sep 17 00:00:00 2001 From: Ulrich Drepper Date: Wed, 14 Apr 1999 13:42:16 +0000 Subject: [PATCH] mmap calls could not be restarted after being interrupted by a signal. The parameters on the stack were corrupted by the signal handler. --- sysdeps/unix/sysv/linux/arm/mmap.S | 22 +++++++++++++++++++--- 1 file changed, 19 insertions(+), 3 deletions(-) diff --git a/sysdeps/unix/sysv/linux/arm/mmap.S b/sysdeps/unix/sysv/linux/arm/mmap.S index f9a773f..fcff57c 100644 --- a/sysdeps/unix/sysv/linux/arm/mmap.S +++ b/sysdeps/unix/sysv/linux/arm/mmap.S @@ -26,10 +26,26 @@ ENTRY (__mmap) mmap() takes six, we need to build a parameter block and pass its address instead. The 386 port does a similar trick. */ - mov ip, sp - stmdb ip!, {a1-a4} - mov a1, ip + /* This code previously moved sp into ip and stored the args using + stmdb ip!, {a1-a4}. It did not modify sp, so the stack never had + to be restored after the syscall completed. It saved an + instruction and meant no stack cleanup work was required. + + This will not work in the case of a mmap call being interrupted + by a signal. If the signal handler uses any stack the arguments + to mmap will be trashed. The results of a restart of mmap are + then unpredictable. */ + + /* store args on the stack */ + stmdb sp!, {a1-a4} + + /* do the syscall */ + mov a1, sp swi SYS_ify (mmap) + + /* pop args off the stack. */ + add sp, sp, #16 + cmn r0, $4096 bhs PLTJMP(syscall_error); ret -- 2.7.4