Reputation: 151
In kernel 3.8.x and later version, the definition for run_init_process is changed.
The following is the new definition for run_init_proces in kernel 3.8.
static int run_init_process(const char *init_filename) {
argv_init[0] = init_filename;
return do_execve(init_filename,
(const char __user *const __user *)argv_init,
(const char __user *const __user *)envp_init); }
Compared to the definition in kernel 3.7.x and old version.
static int run_init_process(const char *init_filename) {
argv_init[0] = init_filename;
return kernel_execve(init_filename, argv_init, envp_init); }
The most critical part in kernel_execve is that it will call the ret_from_kernel_execve, which will switch into the user mode then.
In the new definition, kernel_execve is gone. My question is how the first user process is switched to the user mode then.
Upvotes: 12
Views: 1023
Reputation: 9224
The successful do_execv()
sets up the current
process to run the new program (e.g. via load_elf_binary()
), and then returns 0 to run_init_process()
, which returns 0 to kernel_init()
, which also returns 0, and was called as part of:
kernel_thread(kernel_init, NULL, CLONE_FS | CLONE_SIGHAND);
This is where the rules from https://lwn.net/Articles/520227/ come in: our fn()
has returned 0 after an execve
, so "the thread will proceed into userland context created by that execve".
Upvotes: 1