linux.git/arch/m68k/include/asm/processor.h, branch v3.11

m68knommu: fix trap on execing /bin/init

2013-02-06T01:13:23+00:00

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

m68k: split ret_from_fork(), simplify kernel_thread()

2012-10-01T04:44:44+00:00

Signed-off-by: Al Viro

m68k: always set stack frame format for ColdFire on thread start

2012-10-01T04:44:43+00:00

The stack frame "format" field needs to be explicitly set on thread creation
on ColdFire. For a normal long word aligned user stack pointer the frame
format is 0x4.

We were doing this for non-MMU ColdFire, but not for the case with MMU enabled.
So fix it so we always do it if targeting ColdFire.

The old code happend to rely on the stack frame format being inhereted from
the process calling exec. Furture changes means that may not always work,
so we really do want to set it explicitly.

Signed-off-by: Greg Ungerer 
Signed-off-by: Al Viro

fork: move the real prepare_to_copy() users to arch_dup_task_struct()

2012-05-16T22:16:26+00:00

Historical prepare_to_copy() is mostly a no-op, duplicated for majority of
the architectures and the rest following the x86 model of flushing the extended
register state like fpu there.

Remove it and use the arch_dup_task_struct() instead.

Suggested-by: Oleg Nesterov 
Suggested-by: Linus Torvalds 
Signed-off-by: Suresh Siddha 
Link: http://lkml.kernel.org/r/1336692811-30576-1-git-send-email-suresh.b.siddha@intel.com
Acked-by: Benjamin Herrenschmidt 
Cc: David Howells 
Cc: Koichi Yasutake 
Cc: Paul Mackerras 
Cc: Paul Mundt 
Cc: Chris Zankel 
Cc: Richard Henderson 
Cc: Russell King 
Cc: Haavard Skinnemoen 
Cc: Mike Frysinger 
Cc: Mark Salter 
Cc: Aurelien Jacquiot 
Cc: Mikael Starvik 
Cc: Yoshinori Sato 
Cc: Richard Kuo 
Cc: Tony Luck 
Cc: Michal Simek 
Cc: Ralf Baechle 
Cc: Jonas Bonn 
Cc: James E.J. Bottomley 
Cc: Helge Deller 
Cc: Martin Schwidefsky 
Cc: Heiko Carstens 
Cc: Chen Liqin 
Cc: Lennox Wu 
Cc: David S. Miller 
Cc: Chris Metcalf 
Cc: Jeff Dike 
Cc: Richard Weinberger 
Cc: Guan Xuetao 
Signed-off-by: H. Peter Anvin

m68k: add TASK definitions for ColdFires running with MMU

2011-12-30T00:20:20+00:00

Add appropriate TASK_SIZE and TASK_UNMAPPED_BASE definitions for running
on ColdFire V4e cores with MMU enabled.

Signed-off-by: Greg Ungerer 
Acked-by: Geert Uytterhoeven 
Acked-by: Matt Waddel 
Acked-by: Kurt Mahan

m68k: remove thread_info struct from thread struct

2011-12-24T11:47:56+00:00

Currently on m68k we have a comeplete thread_info structure stored inside
of the thread_struct, and we also have it in the initial part of the kernel
stack. Mostly the code currently uses the one inside of the thread_struct,
only using the "task" pointer from the stack based one.

This is wasteful and confusing, we should only have the single instance of
thread_info inside the stack page. And this is the norm for all other
architectures.

This change makes m68k handle thread_info consistently on both MMU enabled
and non-MMU setups.

Signed-off-by: Greg Ungerer

m68k: merge the mmu and non-mmu traps.c files

2011-10-18T04:22:25+00:00

The code for handling traps in the non-mmu case is a subset of the mmu
enabled case. Merge the non-mmu traps_no.c code back to a single traps.c.
There is actually no code mmu specific here at all, and the processor
specific code (for the more complex 68020/68030/68040/68060) is already
proplerly conditionaly used.

The format of console exception dump is a little different, but I don't
think will cause any one problems, it is purely for debug purposes.

Signed-off-by: Greg Ungerer

m68k, exec: remove redundant set_fs(USER_DS)

2011-07-26T03:57:12+00:00

The address limit is already set in flush_old_exec() so those calls to
set_fs(USER_DS) are redundant.

Signed-off-by: Mathias Krause 
Cc: Greg Ungerer 
Cc: Geert Uytterhoeven 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

m68k: Add helper function handle_kernel_fault()

2011-03-16T18:10:40+00:00

Add helper function handle_kernel_fault() in signal.c, so frame_extra_sizes
can become static, and to avoid future code duplication.

Signed-off-by: Roman Zippel 
Signed-off-by: Geert Uytterhoeven

m68knommu: use user stack pointer hardware on some ColdFire cores

2011-01-05T05:19:18+00:00

The more modern ColdFire parts (even if based on older version cores)
have separate user and supervisor stack pointers (a7 register).
Modify the ColdFire CPU setup and exception code to enable and use
this on parts that have it.

Signed-off-by: Greg Ungerer