lkml.org 
[lkml]   [2012]   [Oct]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: new execve/kernel_thread design
On Wed, Oct 17, 2012 at 04:27:06PM +0200, Michal Simek wrote:

> In the patch above there is directly used current_pt_regs() function
> which works good for newly created threads
> when pt_regs are exactly in current_pt_regs() position but not for
> pt_regs which are saved on the stack
> which is the init task case.

init_task does *not* do kernel_execve(). It's PID 0, not PID 1.
init is spawned by it.

> My question is how should /init be called? Because I need to save
> pt_regs to current_pt_regs() position where
> generic kernel_execve expects it.

What happens during boot is this:
* init_task (not to be confused with init) is used as current during
infrastructure initializations. Once everything needed for scheduler and
for working fork is set, we spawn two threads - future init and future
kthreadd. The last thing we do with init_task is telling init that kthreadd
has been spawned. After that init_task turns itself into an idle thread.
* future init waits for kthreadd to be spawned (it would be more
natural to fork them in opposite order, but we want init to have PID 1 -
too much stuff in userland depends on that). Then it does the rest of
initialization, including setting up initramfs contents. And does
kernel_execve() on /init. Note that this is a task that had been created
by kernel_thread() and is currently in function called from
ret_from_kernel_thread(). Its kernel stack has been set up by copy_thread().
That's where pt_regs need to be set up; note that they'll be passed to
start_thread() before you return to userland. If there are any magic bits
in pt_regs needed by return-from-syscall code, set them in kthread case of
copy_thread().


\
 
 \ /
  Last update: 2012-10-17 18:41    [W:0.239 / U:1.000 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site