aboutsummaryrefslogtreecommitdiff
path: root/arch/m68knommu/kernel/signal.c
AgeCommit message (Collapse)Author
2008-05-01m68knommu: fix signal handling return pathWilson Callan
The return from software signal handling pushes code on the stack that system calls to the kernels cleanup code. This is borrowed directly from the m68k linux signal handler. The rt signal case is not quite right for the restricted instruction set of the ColdFire parts. And neither the normal signal case or rt signal case properly flushes/pushes the appropriate cache lines. Rework the return path to just call back through some code fragments in the kernel proper (with no MMU in the way we can do this). No cache problems, and less code overall. Original patch submitted by Wilson Callan <wcallan@savantav.com> Greg fixed the rt signal return path to use the proper system call Signed-off-by: Greg Ungerer <gerg@uclinux.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-10-23m68knommu: fix syscall restart handlingGreg Ungerer
Fix system call restart handling. We can call directly to the restart handler, no need to back track through trap that isn't even implemented on m68knommu. Signed-off-by: Greg Ungerer <gerg@uclinux.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2006-06-25[PATCH] m68knommu: check DEBUG defined arch codeGreg Ungerer
Don't rely on DEBUG having a value, check for it being defined. Signed-off-by: Greg Ungerer <gerg@uclinux.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-23[PATCH] fix incorrect SA_ONSTACK behaviour for 64-bit processesLaurent MEYER
- When setting a sighandler using sigaction() call, if the flag SA_ONSTACK is set and no alternate stack is provided via sigaltstack(), the kernel still try to install the alternate stack. This behavior is the opposite of the one which is documented in Single Unix Specifications V3. - Also when setting an alternate stack using sigaltstack() with the flag SS_DISABLE, the kernel try to install the alternate stack on signal delivery. These two use cases makes the process crash at signal delivery. Signed-off-by: Laurent Meyer <meyerlau@fr.ibm.com> Cc: Richard Henderson <rth@twiddle.net> Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru> Cc: David Howells <dhowells@redhat.com> Cc: Yoshinori Sato <ysato@users.sourceforge.jp> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Roman Zippel <zippel@linux-m68k.org> Cc: Kyle McMartin <kyle@mcmartin.ca> Cc: Paul Mundt <lethal@linux-sh.org> Cc: Kazumoto Kojima <kkojima@rr.iij4u.or.jp> Cc: Chris Zankel <chris@zankel.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-01-10[PATCH] m68knommu: fix a5 reg corruption in signal handlersGreg Ungerer
This is a patch adapted from a posting by Andrea Tarani which was pointed out to me by Bernardo Innocenti. Thanks to both of them for their help and patience. The original posting is here: http://mailman.uclinux.org/pipermail/uclinux-dev/2005-July/033543.html The problem first manifest itself as busybox ping terminating with an "Illegal instruction". I reduced this to a test case and found that variable size arrays allocated on the stack could lead to stacks not aligned on 32 bit boundaries. For the Coldfire this proved fatal. Having been pointed out this patch by Bernardo, I applied it and it fixed the first test case. I then went back to busybox's ping. This still failed with "Illegal instruction", but in a different way. Before it depended on the size allocated for the ping buffer, now it happened every time. I also found it depended on optimisation level (gcc-3.4.0) -Os was okay but not -O2. After a lot of looking, it turned out that register a5 was being corrupted by the signal handler (after applying the patch). I re-worked the patch a bit to save/restore a5 and now all seems well. Patch submitted by Stuart Hughs <stuarth@freescale.com> Signed-off-by: Greg Ungerer <gerg@uclinux.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-08-29[PATCH] convert signal handling of NODEFER to act like other Unix boxes.Steven Rostedt
It has been reported that the way Linux handles NODEFER for signals is not consistent with the way other Unix boxes handle it. I've written a program to test the behavior of how this flag affects signals and had several reports from people who ran this on various Unix boxes, confirming that Linux seems to be unique on the way this is handled. The way NODEFER affects signals on other Unix boxes is as follows: 1) If NODEFER is set, other signals in sa_mask are still blocked. 2) If NODEFER is set and the signal is in sa_mask, then the signal is still blocked. (Note: this is the behavior of all tested but Linux _and_ NetBSD 2.0 *). The way NODEFER affects signals on Linux: 1) If NODEFER is set, other signals are _not_ blocked regardless of sa_mask (Even NetBSD doesn't do this). 2) If NODEFER is set and the signal is in sa_mask, then the signal being handled is not blocked. The patch converts signal handling in all current Linux architectures to the way most Unix boxes work. Unix boxes that were tested: DU4, AIX 5.2, Irix 6.5, NetBSD 2.0, SFU 3.5 on WinXP, AIX 5.3, Mac OSX, and of course Linux 2.6.13-rcX. * NetBSD was the only other Unix to behave like Linux on point #2. The main concern was brought up by point #1 which even NetBSD isn't like Linux. So with this patch, we leave NetBSD as the lonely one that behaves differently here with #2. Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16Linux-2.6.12-rc2Linus Torvalds
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!