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