summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorBernd Schmidt <bernd.schmidt@analog.com>2007-05-21 18:09:33 +0800
committerLinus Torvalds <torvalds@woody.linux-foundation.org>2007-05-21 09:50:23 -0700
commitc824498db47285aeff430c007685a193b673c949 (patch)
tree685e3736b978199da0588ad14b7e24ee2b7c8d0a
parenta9c59c2746c7e773839d51027c0e16ccf41f8fef (diff)
downloadkernel-crypto-c824498db47285aeff430c007685a193b673c949.tar.gz
kernel-crypto-c824498db47285aeff430c007685a193b673c949.tar.xz
kernel-crypto-c824498db47285aeff430c007685a193b673c949.zip
Blackfin arch: fix signal handling bug
There's a forum thread at https://blackfin.uclinux.org/gf/project/uclinux-dist/forum/?action=ForumBrowse&_forum_action=MessageReply&message_id=24741 which has a testcase involving signal handling that crashes quite readily. Inspecting the code I believe what happens is that signal handling can become confused when it is invoked on return from an interrupt, if the contents of P0 and R0 at the time of the interrupt happen to be such that P0 is larger than zero (indicating to the signal code that we're in a syscall), and R0 happens to have a value of something like -EINTR or -ERESTARTSYS. Fixed by setting orig_p0 to -1 if we're returning from an interrupt. The testcase now seems to run without problems. Signed-off-by: Bernd Schmidt <bernd.schmidt@analog.com> Signed-off-by: Bryan Wu <bryan.wu@analog.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-rw-r--r--arch/blackfin/mach-common/entry.S5
1 files changed, 5 insertions, 0 deletions
diff --git a/arch/blackfin/mach-common/entry.S b/arch/blackfin/mach-common/entry.S
index e463733f5c7..7d0368772cd 100644
--- a/arch/blackfin/mach-common/entry.S
+++ b/arch/blackfin/mach-common/entry.S
@@ -712,6 +712,11 @@ _schedule_and_signal_from_int:
p1.h = _evt_system_call;
[p0] = p1;
csync;
+
+ /* Set orig_p0 to -1 to indicate this isn't the end of a syscall. */
+ r0 = -1 (x);
+ [sp + PT_ORIG_P0] = r0;
+
p1 = rets;
[sp + PT_RESERVED] = p1;