aboutsummaryrefslogtreecommitdiff
path: root/arch/m68k/include/asm
diff options
context:
space:
mode:
authorGreg Ungerer <gerg@uclinux.org>2013-02-06 11:13:23 +1000
committerGreg Ungerer <gerg@uclinux.org>2013-02-06 11:13:23 +1000
commite95c3f7a09ed3996d8ccb9679f3bf38ba9b498d7 (patch)
treee6d625ea7693ec2f474a37108170c0bae626deca /arch/m68k/include/asm
parent88b62b915b0b7e25870eb0604ed9a92ba4bfc9f7 (diff)
m68knommu: fix trap on execing /bin/init
As of commit fea82210 ("m68k: switch to saner kernel_execve() semantics") the non-mmu m68k targets have trapped on booting. The execing of /bin/init causes the exec path to try and return through a 0x0 return address - thus trapping or otherwise hanging or crashing. The problem isn't in the exec path as such though, but rather in the m68knommu start_thread() macro. It is trying to clear the a6 register that it assumes is part of a struct switch_stack below the thread registers on our stack. But that is not what the stack frames look like when this is run. So it ends up corrupting our call stack and zeroing out a function return address that is sitting there. The clearing of a6 was introduced many years ago in commit 7bf9a37d8d ("m68knommu: force stack alignment on ColdFire"). It used to work because the kernel init exec code path had a short cut back to the exception return code, and it didn't need to return through the calls on the stack. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Diffstat (limited to 'arch/m68k/include/asm')
-rw-r--r--arch/m68k/include/asm/processor.h1
1 files changed, 0 insertions, 1 deletions
diff --git a/arch/m68k/include/asm/processor.h b/arch/m68k/include/asm/processor.h
index ae700f49e51d..b0768a657920 100644
--- a/arch/m68k/include/asm/processor.h
+++ b/arch/m68k/include/asm/processor.h
@@ -130,7 +130,6 @@ extern int handle_kernel_fault(struct pt_regs *regs);
#define start_thread(_regs, _pc, _usp) \
do { \
(_regs)->pc = (_pc); \
- ((struct switch_stack *)(_regs))[-1].a6 = 0; \
setframeformat(_regs); \
if (current->mm) \
(_regs)->d5 = current->mm->start_data; \