2012/10/17 Jonas Bonn <jonas@xxxxxxxxxxxx>: > On 17 October 2012 00:35, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote: >> >> Not even a tentative patchset: hexagon, openrisc, tile, xtensa. >> > > I did most of the OpenRISC conversion last weekend... the > kernel_thread bits work fine but I end up with the init thread dying > with what I've got now for kernel_execve. Once I've got that sorted > out, I'll pass this along to you. I am testing the Microblaze conversion and I see the similar problem with GENERIC_KERNEL_EXECVE (commit: http://git.kernel.org/?p=linux/kernel/git/viro/signal.git;a=commit;h=6aa044199aed5b541eba7fe7f25efdfb3a655a58) I have look at the patch and I have found this. (From description above: a kernel thread can become a userland process. The primitive is kernel_execve()) In init/main.c:795/run_init_process() kernel_execve is called. In old style, kernel_execve is called which runs microblaze kernel_execve which calls __NR_execve as syscall. In entry.S user exception detects that jump comes from kernel space and save pt_regs on the current stack and calls sys_execve and then microblaze_execve with 4th argument which is pointer to pt_regs, etc. 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. Also this is the reason why microblaze has implementation for calling _user_exception from the kernel space. I believe that it is called just once for /init. 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. Thanks, Michal -- Michal Simek, Ing. (M.Eng) w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/ Microblaze U-BOOT custodian -- 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
