The current placement of get_signal_to_deliver() means that
try_to_freeze() in get_signal_to_deliver() will happen after
regs->psw.addr, regs->svcnr, and regs->gprs[2] may have been
mangled. Since the app may get checkpointed while frozen and
then restarted, this means we have to attempt a complicated
and subtle re-calculation of the initial conditions.
If we just move the get_signal_to_deliver() above the
immediately preceding block, we enourmously simplify the
arch-specific checkpoint/restart code.
A full ltp run seems to show no regressions do to this move,
though I'm not familiar enough with the entry_64.S code in
particular to be absolutely confident.
Is this a bad idea?
Signed-off-by: Serge E. Hallyn <serue@xxxxxxxxxx>
---
arch/s390/kernel/signal.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/s390/kernel/signal.c b/arch/s390/kernel/signal.c
index 1675c48..7dbd618 100644
--- a/arch/s390/kernel/signal.c
+++ b/arch/s390/kernel/signal.c
@@ -442,6 +442,10 @@ void do_signal(struct pt_regs *regs)
else
oldset = ¤t->blocked;
+ /* Get signal to deliver. When running under ptrace, at this point
+ the debugger may change all our registers ... */
+ signr = get_signal_to_deliver(&info, &ka, regs, NULL);
+
/* Are we from a system call? */
if (regs->svcnr) {
continue_addr = regs->psw.addr;
@@ -463,10 +467,6 @@ void do_signal(struct pt_regs *regs)
regs->svcnr = 0; /* Don't deal with this again. */
}
- /* Get signal to deliver. When running under ptrace, at this point
- the debugger may change all our registers ... */
- signr = get_signal_to_deliver(&info, &ka, regs, NULL);
-
/* Depending on the signal settings we may need to revert the
decision to restart the system call. */
if (signr > 0 && regs->psw.addr == restart_addr) {
--
1.6.1
--
To unsubscribe from this list: send the line "unsubscribe linux-s390" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
