Thread (23 messages) 23 messages, 5 authors, 2012-12-04

Re: new execve/kernel_thread design

From: Al Viro <viro@ZenIV.linux.org.uk>
Date: 2012-10-17 16:20:00
Also in: lkml

Possibly related (same subject, not in this thread)

On Wed, Oct 17, 2012 at 05:07:03PM +0100, Al Viro wrote:
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().
PS: I suspect that we end up with the wrong value in childregs->msr;
start_thread() only add MSR_UMS there.  I'd suggest running the kernel
with these patches + printk childregs->msr the very first time start_thread()
is called and see what it prints, then working kernel + such printk and
compare the results...
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help