There have been reports of problems running UP ppc64 kernels where the
kernel would die in the floating point save/restore code.

It turns out kernel threads that call exec (and so become user tasks) do
not have a valid thread.regs.  This means init (pid 1) does not, it also
means anything called out of exec_usermodehelper does not.  Once that task
has forked (eg init), then the thread.regs in the new task is correctly
set.

On UP do lazy save/restore of floating point regs.  The SLES9 init is doing
floating point (the debian version of init appears not to).  The lack of
thread.regs in init combined with the fact that it does floating point
leads to our lazy FP save/restore code blowing up.

There were other places where this problem exhibited itself in weird and
interesting ways.  If a task being exec'ed out of a kernel thread used more
than 1MB of stack, it would be terminated due to the checks in
arch/ppc64/mm/fault.c (looking for a valid thread.regs when extending the
stack).  We had a test case using the tux webserver that was failing due to
this.

Since we zero all registers in ELF_PLAT_INIT, I removed the extra memset
in start_thread32.
Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>