Re: new execve/kernel_thread design

From: Al Viro
Date: Wed Oct 17 2012 - 12:19:52 EST


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...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/