summaryrefslogtreecommitdiff
path: root/include
diff options
context:
space:
mode:
authorAnton Blanchard <anton@samba.org>2004-09-22 04:20:57 -0700
committerLinus Torvalds <torvalds@ppc970.osdl.org>2004-09-22 04:20:57 -0700
commit8259f7f641e275e1c0cab666ec54945089056fd8 (patch)
treeb7755c3ffe50ec440e1a46dc27ffb722f609eafe /include
parentb5e829113722c211e46f45fe1f13d087e206853d (diff)
[PATCH] ppc64: User tasks must have a valid thread.regs
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>
Diffstat (limited to 'include')
0 files changed, 0 insertions, 0 deletions