[PATCH 1/3] CRISv32: don't attempt syscall restart on irq exit

From: Rabin Vincent
Date: Sun Feb 08 2015 - 15:45:25 EST

r9 is used to determine whether syscall restarting must be performed or
not. Unfortunately, r9 is never set to zero in the non-syscall path,
and r9 is on top of that a callee-saved register which can be set to
non-zero by the C functions that are called during IRQ handling.

This means that if r10 (used for the syscall return value) is one of the
-ERESTART* values when a hardware interrupt occurs which leads to a
signal being delivered to the process, the kernel will "restart" a
syscall which never occurred. This will lead to the PC being moved back
by 2 on return to user space.

Fix the problem by setting r9 to zero in the interrupt path.

Test case (should loop forever but ends up executing the break 8 trap

#include <signal.h>
#include <stdlib.h>
#include <sys/time.h>

void f(int n)
register int r9 asm ("r9") = 1;
register int r10 asm ("r10") = n;

__asm__ __volatile__(
"ba 1f \n"
"nop \n"
"break 8 \n"
"1: ba . \n"
"nop \n"
: "r" (r9), "r" (r10)
: "memory");

void handler1(int sig) { }

int main(int argc, char *argv[])
struct itimerval t1 = { .it_value = {1} };

signal(SIGALRM, handler1);
setitimer(ITIMER_REAL, &t1, NULL);

f(-513); /* -ERESTARTNOINTR */

return 0;

Signed-off-by: Rabin Vincent <rabin@xxxxxx>
arch/cris/arch-v32/kernel/entry.S | 2 ++
1 file changed, 2 insertions(+)

diff --git a/arch/cris/arch-v32/kernel/entry.S b/arch/cris/arch-v32/kernel/entry.S
index 2f19ac6..d4c088b 100644
--- a/arch/cris/arch-v32/kernel/entry.S
+++ b/arch/cris/arch-v32/kernel/entry.S
@@ -99,6 +99,8 @@ ret_from_kernel_thread:

.type ret_from_intr,@function
+ moveq 0, $r9 ; not a syscall
;; Check for resched if preemptive kernel, or if we're going back to
;; user-mode. This test matches the user_regs(regs) macro. Don't simply
;; test CCS since that doesn't necessarily reflect what mode we'll

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/