[PATCH] arch/tile: correct double syscall restart for nested signals

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxx>
---
 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, &current->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-arch" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel]     [Kernel Newbies]     [x86 Platform Driver]     [Netdev]     [Linux Wireless]     [Netfilter]     [Bugtraq]     [Linux Filesystems]     [Yosemite Discussion]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]

  Powered by Linux