infrastructure for saner ret_from_kernel_thread semantics
authorAl Viro <viro@zeniv.linux.org.uk>
Thu, 11 Oct 2012 01:28:25 +0000 (21:28 -0400)
committerAl Viro <viro@zeniv.linux.org.uk>
Fri, 12 Oct 2012 17:35:07 +0000 (13:35 -0400)
commita74fb73c12398b250fdc5e333a11e15a9e3a84fc
tree2bec2f6e20320f5a4bc01d1e19d7190842ef1c37
parentfb45550d76bb584857cf0ea3be79fa78207a3cff
infrastructure for saner ret_from_kernel_thread semantics

* allow kernel_execve() leave the actual return to userland to
caller (selected by CONFIG_GENERIC_KERNEL_EXECVE).  Callers
updated accordingly.
* architecture that does select GENERIC_KERNEL_EXECVE in its
Kconfig should have its ret_from_kernel_thread() do this:
call schedule_tail
call the callback left for it by copy_thread(); if it ever
returns, that's because it has just done successful kernel_execve()
jump to return from syscall
IOW, its only difference from ret_from_fork() is that it does call the
callback.
* such an architecture should also get rid of ret_from_kernel_execve()
and __ARCH_WANT_KERNEL_EXECVE

This is the last part of infrastructure patches in that area - from
that point on work on different architectures can live independently.

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
arch/Kconfig
include/linux/syscalls.h
init/main.c
kernel/kmod.c
kernel/kthread.c