Make restart blocks working, required for proper syscall restarting.
Derived from same changes for m68k arch by Andreas Schwab <schwab@suse.de>
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

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: NGreg Ungerer <gerg@uclinux.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

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: NGreg Ungerer <gerg@uclinux.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Don't rely on DEBUG having a value, check for it being defined.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

- 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: NLaurent 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: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

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: NGreg Ungerer <gerg@uclinux.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

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: NLinus Torvalds <torvalds@osdl.org>

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!