[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <201010282003.o9SK3Sq9006823@farm-0012.internal.tilera.com>
Date: Thu, 28 Oct 2010 15:03:30 -0400
From: Chris Metcalf <cmetcalf@...era.com>
To: Al Viro <viro@...IV.linux.org.uk>
CC: Arnd Bergmann <arnd@...db.de>, <linux-arch@...r.kernel.org>,
<linux-kernel@...r.kernel.org>
Subject: [PATCH] arch/tile: correct double syscall restart for nested signals
This change is modelled on similar fixes for other architectures.
The pt_regs "faultnum" member is set to the trap (fault) number that
caused us to enter the kernel, and is INT_SWINT_1 for the syscall software
interrupt. We already supported a pseudo value, INT_SWINT_1_SIGRETURN,
that we used for the rt_sigreturn syscall; it avoided the case where
one signal was handled, then we "tail-called" to another handler.
This change avoids the similar case where we start to call one handler,
then are preempted into another handler when we start trying to run
the first handler. We clear ->faultnum after calling handle_signal(),
and to be paranoid also in the case where there was no signal to deliver.
Signed-off-by: Chris Metcalf <cmetcalf@...era.com>
---
arch/tile/kernel/signal.c | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/arch/tile/kernel/signal.c b/arch/tile/kernel/signal.c
index fb28e85..704ce0b 100644
--- a/arch/tile/kernel/signal.c
+++ b/arch/tile/kernel/signal.c
@@ -330,7 +330,7 @@ void do_signal(struct pt_regs *regs)
current_thread_info()->status &= ~TS_RESTORE_SIGMASK;
}
- return;
+ goto done;
}
/* Did we come from a system call? */
@@ -358,4 +358,8 @@ void do_signal(struct pt_regs *regs)
current_thread_info()->status &= ~TS_RESTORE_SIGMASK;
sigprocmask(SIG_SETMASK, ¤t->saved_sigmask, NULL);
}
+
+done:
+ /* Avoid double syscall restart if there are nested signals. */
+ regs->faultnum = INT_SWINT_1_SIGRETURN;
}
--
1.6.5.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists