[PATCH] RFC: s390: Move get_signal_to_deliver() up in do_signal

["Serge E. Hallyn" <serue-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>]

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-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
---
 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 = &current->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