Re: [RFC][CFT][CFReview] execve and kernel_thread unification work
On Wed, Oct 17, 2012 at 05:34:24PM +0100, Al Viro wrote: > On Wed, Oct 17, 2012 at 03:02:15PM +0100, Catalin Marinas wrote: > > Hi Al, > > > > On 15 October 2012 02:30, Al Viro wrote: > > > arch-arm64 - patches from maintainer with minor followup folded > > > > Thanks for updating the arm64 branch. I've adapted the changes, tested > > and folded them into the branch below (the AArch64 instruction set > > does not have conditional instructions): > > > > git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/linux-aarch64.git > > execve > > Fetched and merged, thanks. I'll probably drop arch-arm64 branch, now > that I have yours directly merged. In any case, right now arch-arm64 > points to the current head or yours and for-next has > > commit 0cea479343cbfaec3a9b8accdeadae53322d98a8 > Merge: 43cc05a 6a87277 > Author: Al Viro > Date: Wed Oct 17 12:29:32 2012 -0400 > > Merge branch 'execve' of > git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/linux-aarch > > in it... Sounds fine. Thanks. -- Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][CFT][CFReview] execve and kernel_thread unification work
On Wed, Oct 17, 2012 at 03:02:15PM +0100, Catalin Marinas wrote: > Hi Al, > > On 15 October 2012 02:30, Al Viro wrote: > > arch-arm64 - patches from maintainer with minor followup folded > > Thanks for updating the arm64 branch. I've adapted the changes, tested > and folded them into the branch below (the AArch64 instruction set > does not have conditional instructions): > > git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/linux-aarch64.git > execve Fetched and merged, thanks. I'll probably drop arch-arm64 branch, now that I have yours directly merged. In any case, right now arch-arm64 points to the current head or yours and for-next has commit 0cea479343cbfaec3a9b8accdeadae53322d98a8 Merge: 43cc05a 6a87277 Author: Al Viro Date: Wed Oct 17 12:29:32 2012 -0400 Merge branch 'execve' of git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/linux-aarch in it... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][CFT][CFReview] execve and kernel_thread unification work
Hi Al, On 15 October 2012 02:30, Al Viro wrote: > arch-arm64 - patches from maintainer with minor followup folded Thanks for updating the arm64 branch. I've adapted the changes, tested and folded them into the branch below (the AArch64 instruction set does not have conditional instructions): git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/linux-aarch64.git execve Top commit: 6a8727776184f4ac10bd71d926d5e6f2491e (arm64: Use generic sys_execve() implementation) The diff between your branch and mine (including one cosmetic change as the ARM64 Kconfig selects are alphabetically sorted): diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index 31e3b5e..75b212d 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -6,8 +6,8 @@ config ARM64 select GENERIC_IOMAP select GENERIC_IRQ_PROBE select GENERIC_IRQ_SHOW - select GENERIC_KERNEL_THREAD select GENERIC_KERNEL_EXECVE + select GENERIC_KERNEL_THREAD select GENERIC_SMP_IDLE_THREAD select GENERIC_TIME_VSYSCALL select HARDIRQS_SW_RESEND diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S index c3d650a..6165318 100644 --- a/arch/arm64/kernel/entry.S +++ b/arch/arm64/kernel/entry.S @@ -611,10 +611,10 @@ ENDPROC(ret_to_user) */ ENTRY(ret_from_fork) bl schedule_tail - cmp x19, #0 - movne x0, x20 - blnex19 - get_thread_info tsk + cbz x19, 1f // not a kernel thread + mov x0, x20 + blr x19 +1: get_thread_info tsk b ret_to_user ENDPROC(ret_from_fork) -- Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][CFT][CFReview] execve and kernel_thread unification work
Hi Al, On 15/10/12 11:30, Al Viro wrote: On Mon, Oct 01, 2012 at 10:38:09PM +0100, Al Viro wrote: [with apologies for folks Cc'd, resent due to mis-autoexpanded l-k address on the original posting ;-/ Mea culpa...] There's an interesting ongoing project around kernel_thread() and friends, including execve() variants. I really need help from architecture maintainers on that one; I'd been able to handle (and test) quite a few architectures on my own [alpha, arm, m68k, powerpc, s390, sparc, x86, um] plus two more untested [frv, mn10300]. c6x patches had been supplied by Mark Salter; everything else remains to be done. Right now it's at minus 1.2KLoC, quite a bit of that removed from asm glue and other black magic. Update: * all infrastructure is in mainline now, along with conversion for kernel_thread() callbacks to the form that allows really simple model for kernel_execve() _without_ flagday changes. * #experimental-kernel_thread is gone; this stuff is in for-next now. * a lot of architecture conversions had been done and some are even tested. Currently missing are only 7 - avr32, hexagon, m32r, openrisc, score, tile and xtensa. OTOH, a lot are completely untested. I've put per-architecture stuff into separate branches and I promise never rebase those once arch maintainers will be OK with the stuff in them. IOW, they'll be safe to pull into respective architecture trees. Folks, *please* review the stuff in signal.git#arch-*. All of them are completely independent. I'll be glad to get ACKs/fixes/replacements/etc. I have checked arch-m68k on ColdFire with and without MMU, and it is all fine. So for those: Acked-by: Greg Ungerer Regards Greg I've merged some of those into for-next, but that can change at any time - it's not final; for-next will be rebased. Obviously, I hope to get to the situation when all of those branches (plus currently missing ones) get into shape that satisfies architecture maintainers. Once that happens, all those branches will be merged into for-next. I think the model is about final wrt kernel_thread()/kernel_execve()/ sys_execve(). There's one possible change on top of it, but it's reasonably well-isolated from the rest. As it is, the model to aim for is this: * select GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE * kill local kernel_thread()/kernel_execve() implementations * generic kernel_thread() will call your copy_thread() with NULL regs and fn/arg passed in the pair of arguments that are blindly passed all the way through to copy_thread() - usp and stack_size resp. In such case copy_thread() should arrange for the newborn to be woken up in a function that is very similar to ret_from_fork(). The only difference is that between the call of schedule_tail() and jumping into the "return from syscall" code it should call fn(arg), using the data left for it by copy_thread(). * unlike the previous variant, ret_from_kernel_execve() is not needed at all; no need to play longjmp()-like games when kernel_thread() callbacks had been taught to return normally all the way out when kernel_execve() returns 0; any updates of sp/manipulations of register windows/etc. will happen without any magic. * provide current_pt_regs() if needed. Default is task_pt_regs(current), but you might want to optimize it and unlike task_pt_regs() it must work whenever we are in syscall or in a kernel thread. task_pt_regs(task), OTOH, is required to work only when task can be interrogated by tracer. * no more syscalls-from-kernel, which often allows for simplifications in the syscall entry/exit logics. I haven't done any of those; up to the architecture maintainers. One thing to keep in mind is that right now on SMP architectures there's the third caller of copy_thread(), besides fork()/clone()/vfork() (all pass userland pt_regs, with the address being current_pt_regs()) and kernel_thread() (pass NULL pt_regs, kthread creation time). It's fork_idle() and it passes zero-filled pt_regs. Frankly, I'm not even sure we want to call copy_thread() in that case - the stuff set up by it goes nowhere. We do that for each possible secondary CPU on SMP and we do *not* expose those threads to scheduler. When CPU gets initialized we have the secondary bootstrap take that task_struct as current. Its kernel stack, thread_info, etc. are set up by said secondary bootstrap, overriding whatever copy_thread() has done. Eventually the bootstrap reaches cpu_idle(), which is where we schedule away. switch_to() done by schedule() is what completes setting the things up; at that point they are ready to be woken up - and not in ret_from_fork(), of course. For the majority of architectures nothing done by copy_thread() in that case is used afterwards, so we might as well stop calling it when copy_process() is called by fork_idle(). I know of only one dubious case - powerpc sets thread->ksp_limit on
Re: [RFC][CFT][CFReview] execve and kernel_thread unification work
Hi Al, On 15/10/12 11:30, Al Viro wrote: On Mon, Oct 01, 2012 at 10:38:09PM +0100, Al Viro wrote: [with apologies for folks Cc'd, resent due to mis-autoexpanded l-k address on the original posting ;-/ Mea culpa...] There's an interesting ongoing project around kernel_thread() and friends, including execve() variants. I really need help from architecture maintainers on that one; I'd been able to handle (and test) quite a few architectures on my own [alpha, arm, m68k, powerpc, s390, sparc, x86, um] plus two more untested [frv, mn10300]. c6x patches had been supplied by Mark Salter; everything else remains to be done. Right now it's at minus 1.2KLoC, quite a bit of that removed from asm glue and other black magic. Update: * all infrastructure is in mainline now, along with conversion for kernel_thread() callbacks to the form that allows really simple model for kernel_execve() _without_ flagday changes. * #experimental-kernel_thread is gone; this stuff is in for-next now. * a lot of architecture conversions had been done and some are even tested. Currently missing are only 7 - avr32, hexagon, m32r, openrisc, score, tile and xtensa. OTOH, a lot are completely untested. I've put per-architecture stuff into separate branches and I promise never rebase those once arch maintainers will be OK with the stuff in them. IOW, they'll be safe to pull into respective architecture trees. Folks, *please* review the stuff in signal.git#arch-*. All of them are completely independent. I'll be glad to get ACKs/fixes/replacements/etc. I have checked arch-m68k on ColdFire with and without MMU, and it is all fine. So for those: Acked-by: Greg Ungerer g...@uclinux.org Regards Greg I've merged some of those into for-next, but that can change at any time - it's not final; for-next will be rebased. Obviously, I hope to get to the situation when all of those branches (plus currently missing ones) get into shape that satisfies architecture maintainers. Once that happens, all those branches will be merged into for-next. I think the model is about final wrt kernel_thread()/kernel_execve()/ sys_execve(). There's one possible change on top of it, but it's reasonably well-isolated from the rest. As it is, the model to aim for is this: * select GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE * kill local kernel_thread()/kernel_execve() implementations * generic kernel_thread() will call your copy_thread() with NULL regs and fn/arg passed in the pair of arguments that are blindly passed all the way through to copy_thread() - usp and stack_size resp. In such case copy_thread() should arrange for the newborn to be woken up in a function that is very similar to ret_from_fork(). The only difference is that between the call of schedule_tail() and jumping into the return from syscall code it should call fn(arg), using the data left for it by copy_thread(). * unlike the previous variant, ret_from_kernel_execve() is not needed at all; no need to play longjmp()-like games when kernel_thread() callbacks had been taught to return normally all the way out when kernel_execve() returns 0; any updates of sp/manipulations of register windows/etc. will happen without any magic. * provide current_pt_regs() if needed. Default is task_pt_regs(current), but you might want to optimize it and unlike task_pt_regs() it must work whenever we are in syscall or in a kernel thread. task_pt_regs(task), OTOH, is required to work only when task can be interrogated by tracer. * no more syscalls-from-kernel, which often allows for simplifications in the syscall entry/exit logics. I haven't done any of those; up to the architecture maintainers. One thing to keep in mind is that right now on SMP architectures there's the third caller of copy_thread(), besides fork()/clone()/vfork() (all pass userland pt_regs, with the address being current_pt_regs()) and kernel_thread() (pass NULL pt_regs, kthread creation time). It's fork_idle() and it passes zero-filled pt_regs. Frankly, I'm not even sure we want to call copy_thread() in that case - the stuff set up by it goes nowhere. We do that for each possible secondary CPU on SMP and we do *not* expose those threads to scheduler. When CPU gets initialized we have the secondary bootstrap take that task_struct as current. Its kernel stack, thread_info, etc. are set up by said secondary bootstrap, overriding whatever copy_thread() has done. Eventually the bootstrap reaches cpu_idle(), which is where we schedule away. switch_to() done by schedule() is what completes setting the things up; at that point they are ready to be woken up - and not in ret_from_fork(), of course. For the majority of architectures nothing done by copy_thread() in that case is used afterwards, so we might as well stop calling it when copy_process() is called by fork_idle(). I know of only one dubious case - powerpc sets
Re: [RFC][CFT][CFReview] execve and kernel_thread unification work
Hi Al, On 15 October 2012 02:30, Al Viro v...@zeniv.linux.org.uk wrote: arch-arm64 - patches from maintainer with minor followup folded Thanks for updating the arm64 branch. I've adapted the changes, tested and folded them into the branch below (the AArch64 instruction set does not have conditional instructions): git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/linux-aarch64.git execve Top commit: 6a8727776184f4ac10bd71d926d5e6f2491e (arm64: Use generic sys_execve() implementation) The diff between your branch and mine (including one cosmetic change as the ARM64 Kconfig selects are alphabetically sorted): diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index 31e3b5e..75b212d 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -6,8 +6,8 @@ config ARM64 select GENERIC_IOMAP select GENERIC_IRQ_PROBE select GENERIC_IRQ_SHOW - select GENERIC_KERNEL_THREAD select GENERIC_KERNEL_EXECVE + select GENERIC_KERNEL_THREAD select GENERIC_SMP_IDLE_THREAD select GENERIC_TIME_VSYSCALL select HARDIRQS_SW_RESEND diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S index c3d650a..6165318 100644 --- a/arch/arm64/kernel/entry.S +++ b/arch/arm64/kernel/entry.S @@ -611,10 +611,10 @@ ENDPROC(ret_to_user) */ ENTRY(ret_from_fork) bl schedule_tail - cmp x19, #0 - movne x0, x20 - blnex19 - get_thread_info tsk + cbz x19, 1f // not a kernel thread + mov x0, x20 + blr x19 +1: get_thread_info tsk b ret_to_user ENDPROC(ret_from_fork) -- Catalin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][CFT][CFReview] execve and kernel_thread unification work
On Wed, Oct 17, 2012 at 03:02:15PM +0100, Catalin Marinas wrote: Hi Al, On 15 October 2012 02:30, Al Viro v...@zeniv.linux.org.uk wrote: arch-arm64 - patches from maintainer with minor followup folded Thanks for updating the arm64 branch. I've adapted the changes, tested and folded them into the branch below (the AArch64 instruction set does not have conditional instructions): git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/linux-aarch64.git execve Fetched and merged, thanks. I'll probably drop arch-arm64 branch, now that I have yours directly merged. In any case, right now arch-arm64 points to the current head or yours and for-next has commit 0cea479343cbfaec3a9b8accdeadae53322d98a8 Merge: 43cc05a 6a87277 Author: Al Viro v...@zeniv.linux.org.uk Date: Wed Oct 17 12:29:32 2012 -0400 Merge branch 'execve' of git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/linux-aarch in it... -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][CFT][CFReview] execve and kernel_thread unification work
On Wed, Oct 17, 2012 at 05:34:24PM +0100, Al Viro wrote: On Wed, Oct 17, 2012 at 03:02:15PM +0100, Catalin Marinas wrote: Hi Al, On 15 October 2012 02:30, Al Viro v...@zeniv.linux.org.uk wrote: arch-arm64 - patches from maintainer with minor followup folded Thanks for updating the arm64 branch. I've adapted the changes, tested and folded them into the branch below (the AArch64 instruction set does not have conditional instructions): git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/linux-aarch64.git execve Fetched and merged, thanks. I'll probably drop arch-arm64 branch, now that I have yours directly merged. In any case, right now arch-arm64 points to the current head or yours and for-next has commit 0cea479343cbfaec3a9b8accdeadae53322d98a8 Merge: 43cc05a 6a87277 Author: Al Viro v...@zeniv.linux.org.uk Date: Wed Oct 17 12:29:32 2012 -0400 Merge branch 'execve' of git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/linux-aarch in it... Sounds fine. Thanks. -- Catalin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][CFT][CFReview] execve and kernel_thread unification work
On Mon, Oct 01, 2012 at 10:38:09PM +0100, Al Viro wrote: > [with apologies for folks Cc'd, resent due to mis-autoexpanded l-k address > on the original posting ;-/ Mea culpa...] > > There's an interesting ongoing project around kernel_thread() and > friends, including execve() variants. I really need help from architecture > maintainers on that one; I'd been able to handle (and test) quite a few > architectures on my own [alpha, arm, m68k, powerpc, s390, sparc, x86, um] > plus two more untested [frv, mn10300]. c6x patches had been supplied by > Mark Salter; everything else remains to be done. Right now it's at > minus 1.2KLoC, quite a bit of that removed from asm glue and other black > magic. Update: * all infrastructure is in mainline now, along with conversion for kernel_thread() callbacks to the form that allows really simple model for kernel_execve() _without_ flagday changes. * #experimental-kernel_thread is gone; this stuff is in for-next now. * a lot of architecture conversions had been done and some are even tested. Currently missing are only 7 - avr32, hexagon, m32r, openrisc, score, tile and xtensa. OTOH, a lot are completely untested. I've put per-architecture stuff into separate branches and I promise never rebase those once arch maintainers will be OK with the stuff in them. IOW, they'll be safe to pull into respective architecture trees. Folks, *please* review the stuff in signal.git#arch-*. All of them are completely independent. I'll be glad to get ACKs/fixes/replacements/etc. I've merged some of those into for-next, but that can change at any time - it's not final; for-next will be rebased. Obviously, I hope to get to the situation when all of those branches (plus currently missing ones) get into shape that satisfies architecture maintainers. Once that happens, all those branches will be merged into for-next. I think the model is about final wrt kernel_thread()/kernel_execve()/ sys_execve(). There's one possible change on top of it, but it's reasonably well-isolated from the rest. As it is, the model to aim for is this: * select GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE * kill local kernel_thread()/kernel_execve() implementations * generic kernel_thread() will call your copy_thread() with NULL regs and fn/arg passed in the pair of arguments that are blindly passed all the way through to copy_thread() - usp and stack_size resp. In such case copy_thread() should arrange for the newborn to be woken up in a function that is very similar to ret_from_fork(). The only difference is that between the call of schedule_tail() and jumping into the "return from syscall" code it should call fn(arg), using the data left for it by copy_thread(). * unlike the previous variant, ret_from_kernel_execve() is not needed at all; no need to play longjmp()-like games when kernel_thread() callbacks had been taught to return normally all the way out when kernel_execve() returns 0; any updates of sp/manipulations of register windows/etc. will happen without any magic. * provide current_pt_regs() if needed. Default is task_pt_regs(current), but you might want to optimize it and unlike task_pt_regs() it must work whenever we are in syscall or in a kernel thread. task_pt_regs(task), OTOH, is required to work only when task can be interrogated by tracer. * no more syscalls-from-kernel, which often allows for simplifications in the syscall entry/exit logics. I haven't done any of those; up to the architecture maintainers. One thing to keep in mind is that right now on SMP architectures there's the third caller of copy_thread(), besides fork()/clone()/vfork() (all pass userland pt_regs, with the address being current_pt_regs()) and kernel_thread() (pass NULL pt_regs, kthread creation time). It's fork_idle() and it passes zero-filled pt_regs. Frankly, I'm not even sure we want to call copy_thread() in that case - the stuff set up by it goes nowhere. We do that for each possible secondary CPU on SMP and we do *not* expose those threads to scheduler. When CPU gets initialized we have the secondary bootstrap take that task_struct as current. Its kernel stack, thread_info, etc. are set up by said secondary bootstrap, overriding whatever copy_thread() has done. Eventually the bootstrap reaches cpu_idle(), which is where we schedule away. switch_to() done by schedule() is what completes setting the things up; at that point they are ready to be woken up - and not in ret_from_fork(), of course. For the majority of architectures nothing done by copy_thread() in that case is used afterwards, so we might as well stop calling it when copy_process() is called by fork_idle(). I know of only one dubious case - powerpc sets thread->ksp_limit on copy_thread() and I'm not sure if that's get overwritten in secondary bootstrap - the value would be still correct and I don't see any obvious places where it would be
Re: [RFC][CFT][CFReview] execve and kernel_thread unification work
On Mon, Oct 01, 2012 at 10:38:09PM +0100, Al Viro wrote: [with apologies for folks Cc'd, resent due to mis-autoexpanded l-k address on the original posting ;-/ Mea culpa...] There's an interesting ongoing project around kernel_thread() and friends, including execve() variants. I really need help from architecture maintainers on that one; I'd been able to handle (and test) quite a few architectures on my own [alpha, arm, m68k, powerpc, s390, sparc, x86, um] plus two more untested [frv, mn10300]. c6x patches had been supplied by Mark Salter; everything else remains to be done. Right now it's at minus 1.2KLoC, quite a bit of that removed from asm glue and other black magic. Update: * all infrastructure is in mainline now, along with conversion for kernel_thread() callbacks to the form that allows really simple model for kernel_execve() _without_ flagday changes. * #experimental-kernel_thread is gone; this stuff is in for-next now. * a lot of architecture conversions had been done and some are even tested. Currently missing are only 7 - avr32, hexagon, m32r, openrisc, score, tile and xtensa. OTOH, a lot are completely untested. I've put per-architecture stuff into separate branches and I promise never rebase those once arch maintainers will be OK with the stuff in them. IOW, they'll be safe to pull into respective architecture trees. Folks, *please* review the stuff in signal.git#arch-*. All of them are completely independent. I'll be glad to get ACKs/fixes/replacements/etc. I've merged some of those into for-next, but that can change at any time - it's not final; for-next will be rebased. Obviously, I hope to get to the situation when all of those branches (plus currently missing ones) get into shape that satisfies architecture maintainers. Once that happens, all those branches will be merged into for-next. I think the model is about final wrt kernel_thread()/kernel_execve()/ sys_execve(). There's one possible change on top of it, but it's reasonably well-isolated from the rest. As it is, the model to aim for is this: * select GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE * kill local kernel_thread()/kernel_execve() implementations * generic kernel_thread() will call your copy_thread() with NULL regs and fn/arg passed in the pair of arguments that are blindly passed all the way through to copy_thread() - usp and stack_size resp. In such case copy_thread() should arrange for the newborn to be woken up in a function that is very similar to ret_from_fork(). The only difference is that between the call of schedule_tail() and jumping into the return from syscall code it should call fn(arg), using the data left for it by copy_thread(). * unlike the previous variant, ret_from_kernel_execve() is not needed at all; no need to play longjmp()-like games when kernel_thread() callbacks had been taught to return normally all the way out when kernel_execve() returns 0; any updates of sp/manipulations of register windows/etc. will happen without any magic. * provide current_pt_regs() if needed. Default is task_pt_regs(current), but you might want to optimize it and unlike task_pt_regs() it must work whenever we are in syscall or in a kernel thread. task_pt_regs(task), OTOH, is required to work only when task can be interrogated by tracer. * no more syscalls-from-kernel, which often allows for simplifications in the syscall entry/exit logics. I haven't done any of those; up to the architecture maintainers. One thing to keep in mind is that right now on SMP architectures there's the third caller of copy_thread(), besides fork()/clone()/vfork() (all pass userland pt_regs, with the address being current_pt_regs()) and kernel_thread() (pass NULL pt_regs, kthread creation time). It's fork_idle() and it passes zero-filled pt_regs. Frankly, I'm not even sure we want to call copy_thread() in that case - the stuff set up by it goes nowhere. We do that for each possible secondary CPU on SMP and we do *not* expose those threads to scheduler. When CPU gets initialized we have the secondary bootstrap take that task_struct as current. Its kernel stack, thread_info, etc. are set up by said secondary bootstrap, overriding whatever copy_thread() has done. Eventually the bootstrap reaches cpu_idle(), which is where we schedule away. switch_to() done by schedule() is what completes setting the things up; at that point they are ready to be woken up - and not in ret_from_fork(), of course. For the majority of architectures nothing done by copy_thread() in that case is used afterwards, so we might as well stop calling it when copy_process() is called by fork_idle(). I know of only one dubious case - powerpc sets thread-ksp_limit on copy_thread() and I'm not sure if that's get overwritten in secondary bootstrap - the value would be still correct and I don't see any obvious places where it would be reassigned on
Re: [git pull] signal.git, pile 2 (was Re: [RFC][CFT][CFReview] execve and kernel_thread unification work)
On Fri, 2012-10-12 at 02:09 +0100, Al Viro wrote: > Anyway, if ppc folks can live with that stuff in its current form for now, > here's the second signal.git pull request. Stuff in there: kernel_thread/ > kernel_execve/sys_execve conversions for several more architectures plus > assorted signal fixes and cleanups. There'll be more (in particular, real > fixes for alpha do_notify_resume() irq mess)... Linus, could you pull that > queue? It's in the usual place - > git://git.kernel.org/pub/scm/linux/kernel/git/viro/signal for-linus Yes, we can live with what's in there, it won't break anything. We can do the proposed cleanups subsequently. Cheers, Ben. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [git pull] signal.git, pile 2 (was Re: [RFC][CFT][CFReview] execve and kernel_thread unification work)
On Fri, 2012-10-12 at 02:09 +0100, Al Viro wrote: Anyway, if ppc folks can live with that stuff in its current form for now, here's the second signal.git pull request. Stuff in there: kernel_thread/ kernel_execve/sys_execve conversions for several more architectures plus assorted signal fixes and cleanups. There'll be more (in particular, real fixes for alpha do_notify_resume() irq mess)... Linus, could you pull that queue? It's in the usual place - git://git.kernel.org/pub/scm/linux/kernel/git/viro/signal for-linus Yes, we can live with what's in there, it won't break anything. We can do the proposed cleanups subsequently. Cheers, Ben. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [git pull] signal.git, pile 2 (was Re: [RFC][CFT][CFReview] execve and kernel_thread unification work)
On Fri, Oct 12, 2012 at 02:09:58AM +0100, Al Viro wrote: > > How granular are you planning to make that? I mean, we are talking about > 3 objects here - init/main.o, kernel/kthread.o and kernel/kmod.o. Do they > get TOC separate from that of arch/powerpc/kernel/entry_64.o? Potentially, yes, it would be up to the linker. > Anyway, if ppc folks can live with that stuff in its current form for now, Yes, we can. Paul. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[git pull] signal.git, pile 2 (was Re: [RFC][CFT][CFReview] execve and kernel_thread unification work)
On Fri, Oct 12, 2012 at 11:16:33AM +1100, Paul Mackerras wrote:
> On Thu, Oct 11, 2012 at 01:53:06PM +0100, Al Viro wrote:
>
> > Umm... Maybe, but let's do that as subsequent cleanup. Again,
> > we almost certainly don't need to mess with TOC at all - the callbacks
> > are in the main kernel, there are very few of them and they really are
> > low-level details of exported mechanisms (i.e. kthread_create/run/etc.
> > in kthread.h and call_usermode... in kmod.h). Again, we are talking
> > about out-of-tree modules, they had better mechanism for at least
> > 6 years and conversion to it is bloody trivial. Hell, it was even
> > in late unlamented feature-removal-schedule.txt - since 2006. If that's
> > not enough to retire an export, what is?
>
> OK... yes we can fix things up in a subsequent cleanup.
>
> We will need to fix the TOC handling when we go to using multiple TOCs
> in the main kernel, with the linker managing the transitions between
> TOCs. Our toolchain guys have been pushing us to do that for years,
> because it should make things run faster, but first we'll have to stop
> using ld -r to combine objects in subdirectories.
How granular are you planning to make that? I mean, we are talking about
3 objects here - init/main.o, kernel/kthread.o and kernel/kmod.o. Do they
get TOC separate from that of arch/powerpc/kernel/entry_64.o?
Anyway, if ppc folks can live with that stuff in its current form for now,
here's the second signal.git pull request. Stuff in there: kernel_thread/
kernel_execve/sys_execve conversions for several more architectures plus
assorted signal fixes and cleanups. There'll be more (in particular, real
fixes for alpha do_notify_resume() irq mess)... Linus, could you pull that
queue? It's in the usual place -
git://git.kernel.org/pub/scm/linux/kernel/git/viro/signal for-linus
Shortlog:
Al Viro (38):
powerpc: split ret_from_fork
powerpc: switch to generic sys_execve()/kernel_execve()
m68k: split ret_from_fork(), simplify kernel_thread()
m68k: switch to generic sys_execve()/kernel_execve()
frv: split ret_from_fork, simplify kernel_thread() a lot
frv: switch to generic sys_execve()
frv: switch to generic kernel_execve
frv: switch to generic kernel_thread()
mn10300: split ret_from_fork, simplify kernel_thread()
mn10300: switch to generic sys_execve()
mn10300: switch to generic kernel_execve()
mn10300: convert to generic kernel_thread()
c6x: switch to generic kernel_thread()
xtensa: can't get to do_notify_resume() when user_mode(regs) is not true
mn10300: get rid of calling do_notify_resume() when returning to kernel
mode
score: fix bogus restarts on sigreturn()
ia64: can't reach do_signal() when returning to kernel mode
mips: prevent hitting do_notify_resume() with !user_mode(regs)
mips: unobfuscate _TIF..._MASK
mips: merge the identical "return from syscall" per-ABI code
mips: NOTIFY_RESUME is not needed in TIF masks
unicore32: unobfuscate _TIF_WORK_MASK
bury _TIF_RESTORE_SIGMASK
sanitize tsk_is_polling()
bury the rest of TIF_IRET
parisc: fix double restarts
parisc: don't bother looping in do_signal()
parisc: decide whether to go to slow path (tracesys) based on thread flags
h8300: trim _TIF_WORK_MASK
unicore32: remove pointless test
x86: get rid of duplicate code in case of CONFIG_VM86
frv: no need to raise SIGTRAP in setup_frame()
mn10300: don't bother with SIGTRAP in setup_frame()
microblaze: don't bother with SIGTRAP in setup_rt_frame()
tile: don't bother with SIGTRAP in setup_frame
avr32: trim masks
m32r: trim masks
alpha: don't open-code trace_report_syscall_{enter,exit}
Greg Ungerer (1):
m68k: always set stack frame format for ColdFire on thread start
Mark Salter (3):
c6x: add ret_from_kernel_thread(), simplify kernel_thread()
c6x: switch to generic kernel_execve
c6x: switch to generic sys_execve
Richard Weinberger (1):
Uninclude linux/freezer.h
Diffstat:
arch/alpha/include/asm/thread_info.h |3 +-
arch/alpha/kernel/entry.S | 13 ++--
arch/alpha/kernel/ptrace.c| 32 -
arch/arm/include/asm/thread_info.h|2 -
arch/arm/kernel/signal.c |1 -
arch/avr32/include/asm/thread_info.h | 18 ++---
arch/avr32/kernel/signal.c|1 -
arch/blackfin/include/asm/thread_info.h |4 -
arch/blackfin/kernel/signal.c |1 -
arch/c6x/Kconfig |1 +
arch/c6x/include/asm/processor.h |2 -
arch/c6x/include/asm/syscalls.h |5 --
arch/c6x/include/asm/thread_info.h|1 -
arch/c6x/include/asm/unistd.h |3 +
arch/c6x/kernel/asm-offsets.c |1 -
arch/c6x/kernel/entry.S | 56
Re: [RFC][CFT][CFReview] execve and kernel_thread unification work
On Thu, Oct 11, 2012 at 01:53:06PM +0100, Al Viro wrote: > Umm... Maybe, but let's do that as subsequent cleanup. Again, > we almost certainly don't need to mess with TOC at all - the callbacks > are in the main kernel, there are very few of them and they really are > low-level details of exported mechanisms (i.e. kthread_create/run/etc. > in kthread.h and call_usermode... in kmod.h). Again, we are talking > about out-of-tree modules, they had better mechanism for at least > 6 years and conversion to it is bloody trivial. Hell, it was even > in late unlamented feature-removal-schedule.txt - since 2006. If that's > not enough to retire an export, what is? OK... yes we can fix things up in a subsequent cleanup. We will need to fix the TOC handling when we go to using multiple TOCs in the main kernel, with the linker managing the transitions between TOCs. Our toolchain guys have been pushing us to do that for years, because it should make things run faster, but first we'll have to stop using ld -r to combine objects in subdirectories. Paul. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][CFT][CFReview] execve and kernel_thread unification work
On Thu, Oct 11, 2012 at 08:00:23PM +1100, Paul Mackerras wrote:
> I just looked through the "powerpc: split ret_from_fork" commit in
> your for-next branch, and I have a couple of comments.
>
> First, on 64-bit powerpc, if kernel_thread() is called on a function
> in a module, and that function returns, we'll then jump to do_exit
> with r2 pointing to the module's TOC rather than the main kernel's
> TOC, with disastrous results. It would be easily solved by adding a
>
> ld r2,PACATOC(r13)
>
> before the branch to .do_exit in the 64-bit ret_from_kernel_thread().
> Maybe no-one ever calls kernel_thread() on a function in a module
> today, but I don't want to rely on that being true forever, especially
> since it's only one more instruction to guard against the possibility.
It's unexported, and for a good reason. So no, there won't be any callers
in modules. The good reasons in question:
* it's trivial to convert any such caller to kthread_run() and
kthread.h in general
* there are only ~7 callers in the mainline, all but one in
{init,kernel}/*.c. Said exception is in arch/powerpc, also non-modular
and there conversion is simply
- set_task_comm(current, "eehd");
in eeh_event_handler,
- if (kernel_thread(eeh_event_handler, NULL, CLONE_KERNEL) < 0)
+ if (IS_ERR(kthread_run(eeh_event_handler, NULL, "eehd")))
in eeh_thread_launcher, plus adding #include .
All there is to it.
* life is going to become much simpler if we change kernel_thread()
callback semantics (while leaving kthread.h and kmod.h behaviour intact)
and I'm going to do that later in the series. This call of do_exit() is
going away, to start with - from any asm glue. Better have it done in
kernel/kmod.c - all it takes is a couple of lines in there, everything
else already never returns, either by looping forever or by successful
execve(2) or by exit(2) (or panic(), in one case). Again, I'm talking about
kernel_thread() callbacks - kthread.h ones already have do_exit() done by
their caller (which is a kernel_thread() callback in kernel/kthread.c).
And then we can do even better - check signal.git#experimental-kernel_thread
and you'll see.
IOW, being able to treat that as internal low-level mechanism rather than
any kind of stable API for modules is a very good thing.
> Secondly, while the code as you have it is correct, to my mind it
> would be cleaner to put the function descriptor address in r14 on
> 64-bit, rather than the function text address, and then dereference it
> to get the TOC and text address at the point of doing the call. That
> would reduce the differences between 32-bit and 64-bit in
> copy_thread() and make it more obvious that ret_from_kernel_thread()
> is setting the right TOC value in r2.
Umm... Maybe, but let's do that as subsequent cleanup. Again,
we almost certainly don't need to mess with TOC at all - the callbacks
are in the main kernel, there are very few of them and they really are
low-level details of exported mechanisms (i.e. kthread_create/run/etc.
in kthread.h and call_usermode... in kmod.h). Again, we are talking
about out-of-tree modules, they had better mechanism for at least
6 years and conversion to it is bloody trivial. Hell, it was even
in late unlamented feature-removal-schedule.txt - since 2006. If that's
not enough to retire an export, what is?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][CFT][CFReview] execve and kernel_thread unification work
I just looked through the "powerpc: split ret_from_fork" commit in your for-next branch, and I have a couple of comments. First, on 64-bit powerpc, if kernel_thread() is called on a function in a module, and that function returns, we'll then jump to do_exit with r2 pointing to the module's TOC rather than the main kernel's TOC, with disastrous results. It would be easily solved by adding a ld r2,PACATOC(r13) before the branch to .do_exit in the 64-bit ret_from_kernel_thread(). Maybe no-one ever calls kernel_thread() on a function in a module today, but I don't want to rely on that being true forever, especially since it's only one more instruction to guard against the possibility. Secondly, while the code as you have it is correct, to my mind it would be cleaner to put the function descriptor address in r14 on 64-bit, rather than the function text address, and then dereference it to get the TOC and text address at the point of doing the call. That would reduce the differences between 32-bit and 64-bit in copy_thread() and make it more obvious that ret_from_kernel_thread() is setting the right TOC value in r2. In fact copy_thread() doesn't need to set r2 in the 32-bit case, since _switch() sets r2 to the task_struct for the task it's switching to, and ignores the r2 value in the stack frame. So with my suggestion copy_thread() wouldn't need to set childregs->gpr[2] at all (for the kernel thread case). Paul. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][CFT][CFReview] execve and kernel_thread unification work
I just looked through the powerpc: split ret_from_fork commit in your for-next branch, and I have a couple of comments. First, on 64-bit powerpc, if kernel_thread() is called on a function in a module, and that function returns, we'll then jump to do_exit with r2 pointing to the module's TOC rather than the main kernel's TOC, with disastrous results. It would be easily solved by adding a ld r2,PACATOC(r13) before the branch to .do_exit in the 64-bit ret_from_kernel_thread(). Maybe no-one ever calls kernel_thread() on a function in a module today, but I don't want to rely on that being true forever, especially since it's only one more instruction to guard against the possibility. Secondly, while the code as you have it is correct, to my mind it would be cleaner to put the function descriptor address in r14 on 64-bit, rather than the function text address, and then dereference it to get the TOC and text address at the point of doing the call. That would reduce the differences between 32-bit and 64-bit in copy_thread() and make it more obvious that ret_from_kernel_thread() is setting the right TOC value in r2. In fact copy_thread() doesn't need to set r2 in the 32-bit case, since _switch() sets r2 to the task_struct for the task it's switching to, and ignores the r2 value in the stack frame. So with my suggestion copy_thread() wouldn't need to set childregs-gpr[2] at all (for the kernel thread case). Paul. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][CFT][CFReview] execve and kernel_thread unification work
On Thu, Oct 11, 2012 at 08:00:23PM +1100, Paul Mackerras wrote:
I just looked through the powerpc: split ret_from_fork commit in
your for-next branch, and I have a couple of comments.
First, on 64-bit powerpc, if kernel_thread() is called on a function
in a module, and that function returns, we'll then jump to do_exit
with r2 pointing to the module's TOC rather than the main kernel's
TOC, with disastrous results. It would be easily solved by adding a
ld r2,PACATOC(r13)
before the branch to .do_exit in the 64-bit ret_from_kernel_thread().
Maybe no-one ever calls kernel_thread() on a function in a module
today, but I don't want to rely on that being true forever, especially
since it's only one more instruction to guard against the possibility.
It's unexported, and for a good reason. So no, there won't be any callers
in modules. The good reasons in question:
* it's trivial to convert any such caller to kthread_run() and
kthread.h in general
* there are only ~7 callers in the mainline, all but one in
{init,kernel}/*.c. Said exception is in arch/powerpc, also non-modular
and there conversion is simply
- set_task_comm(current, eehd);
in eeh_event_handler,
- if (kernel_thread(eeh_event_handler, NULL, CLONE_KERNEL) 0)
+ if (IS_ERR(kthread_run(eeh_event_handler, NULL, eehd)))
in eeh_thread_launcher, plus adding #include linux/kthread.h.
All there is to it.
* life is going to become much simpler if we change kernel_thread()
callback semantics (while leaving kthread.h and kmod.h behaviour intact)
and I'm going to do that later in the series. This call of do_exit() is
going away, to start with - from any asm glue. Better have it done in
kernel/kmod.c - all it takes is a couple of lines in there, everything
else already never returns, either by looping forever or by successful
execve(2) or by exit(2) (or panic(), in one case). Again, I'm talking about
kernel_thread() callbacks - kthread.h ones already have do_exit() done by
their caller (which is a kernel_thread() callback in kernel/kthread.c).
And then we can do even better - check signal.git#experimental-kernel_thread
and you'll see.
IOW, being able to treat that as internal low-level mechanism rather than
any kind of stable API for modules is a very good thing.
Secondly, while the code as you have it is correct, to my mind it
would be cleaner to put the function descriptor address in r14 on
64-bit, rather than the function text address, and then dereference it
to get the TOC and text address at the point of doing the call. That
would reduce the differences between 32-bit and 64-bit in
copy_thread() and make it more obvious that ret_from_kernel_thread()
is setting the right TOC value in r2.
Umm... Maybe, but let's do that as subsequent cleanup. Again,
we almost certainly don't need to mess with TOC at all - the callbacks
are in the main kernel, there are very few of them and they really are
low-level details of exported mechanisms (i.e. kthread_create/run/etc.
in kthread.h and call_usermode... in kmod.h). Again, we are talking
about out-of-tree modules, they had better mechanism for at least
6 years and conversion to it is bloody trivial. Hell, it was even
in late unlamented feature-removal-schedule.txt - since 2006. If that's
not enough to retire an export, what is?
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][CFT][CFReview] execve and kernel_thread unification work
On Thu, Oct 11, 2012 at 01:53:06PM +0100, Al Viro wrote: Umm... Maybe, but let's do that as subsequent cleanup. Again, we almost certainly don't need to mess with TOC at all - the callbacks are in the main kernel, there are very few of them and they really are low-level details of exported mechanisms (i.e. kthread_create/run/etc. in kthread.h and call_usermode... in kmod.h). Again, we are talking about out-of-tree modules, they had better mechanism for at least 6 years and conversion to it is bloody trivial. Hell, it was even in late unlamented feature-removal-schedule.txt - since 2006. If that's not enough to retire an export, what is? OK... yes we can fix things up in a subsequent cleanup. We will need to fix the TOC handling when we go to using multiple TOCs in the main kernel, with the linker managing the transitions between TOCs. Our toolchain guys have been pushing us to do that for years, because it should make things run faster, but first we'll have to stop using ld -r to combine objects in subdirectories. Paul. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[git pull] signal.git, pile 2 (was Re: [RFC][CFT][CFReview] execve and kernel_thread unification work)
On Fri, Oct 12, 2012 at 11:16:33AM +1100, Paul Mackerras wrote:
On Thu, Oct 11, 2012 at 01:53:06PM +0100, Al Viro wrote:
Umm... Maybe, but let's do that as subsequent cleanup. Again,
we almost certainly don't need to mess with TOC at all - the callbacks
are in the main kernel, there are very few of them and they really are
low-level details of exported mechanisms (i.e. kthread_create/run/etc.
in kthread.h and call_usermode... in kmod.h). Again, we are talking
about out-of-tree modules, they had better mechanism for at least
6 years and conversion to it is bloody trivial. Hell, it was even
in late unlamented feature-removal-schedule.txt - since 2006. If that's
not enough to retire an export, what is?
OK... yes we can fix things up in a subsequent cleanup.
We will need to fix the TOC handling when we go to using multiple TOCs
in the main kernel, with the linker managing the transitions between
TOCs. Our toolchain guys have been pushing us to do that for years,
because it should make things run faster, but first we'll have to stop
using ld -r to combine objects in subdirectories.
How granular are you planning to make that? I mean, we are talking about
3 objects here - init/main.o, kernel/kthread.o and kernel/kmod.o. Do they
get TOC separate from that of arch/powerpc/kernel/entry_64.o?
Anyway, if ppc folks can live with that stuff in its current form for now,
here's the second signal.git pull request. Stuff in there: kernel_thread/
kernel_execve/sys_execve conversions for several more architectures plus
assorted signal fixes and cleanups. There'll be more (in particular, real
fixes for alpha do_notify_resume() irq mess)... Linus, could you pull that
queue? It's in the usual place -
git://git.kernel.org/pub/scm/linux/kernel/git/viro/signal for-linus
Shortlog:
Al Viro (38):
powerpc: split ret_from_fork
powerpc: switch to generic sys_execve()/kernel_execve()
m68k: split ret_from_fork(), simplify kernel_thread()
m68k: switch to generic sys_execve()/kernel_execve()
frv: split ret_from_fork, simplify kernel_thread() a lot
frv: switch to generic sys_execve()
frv: switch to generic kernel_execve
frv: switch to generic kernel_thread()
mn10300: split ret_from_fork, simplify kernel_thread()
mn10300: switch to generic sys_execve()
mn10300: switch to generic kernel_execve()
mn10300: convert to generic kernel_thread()
c6x: switch to generic kernel_thread()
xtensa: can't get to do_notify_resume() when user_mode(regs) is not true
mn10300: get rid of calling do_notify_resume() when returning to kernel
mode
score: fix bogus restarts on sigreturn()
ia64: can't reach do_signal() when returning to kernel mode
mips: prevent hitting do_notify_resume() with !user_mode(regs)
mips: unobfuscate _TIF..._MASK
mips: merge the identical return from syscall per-ABI code
mips: NOTIFY_RESUME is not needed in TIF masks
unicore32: unobfuscate _TIF_WORK_MASK
bury _TIF_RESTORE_SIGMASK
sanitize tsk_is_polling()
bury the rest of TIF_IRET
parisc: fix double restarts
parisc: don't bother looping in do_signal()
parisc: decide whether to go to slow path (tracesys) based on thread flags
h8300: trim _TIF_WORK_MASK
unicore32: remove pointless test
x86: get rid of duplicate code in case of CONFIG_VM86
frv: no need to raise SIGTRAP in setup_frame()
mn10300: don't bother with SIGTRAP in setup_frame()
microblaze: don't bother with SIGTRAP in setup_rt_frame()
tile: don't bother with SIGTRAP in setup_frame
avr32: trim masks
m32r: trim masks
alpha: don't open-code trace_report_syscall_{enter,exit}
Greg Ungerer (1):
m68k: always set stack frame format for ColdFire on thread start
Mark Salter (3):
c6x: add ret_from_kernel_thread(), simplify kernel_thread()
c6x: switch to generic kernel_execve
c6x: switch to generic sys_execve
Richard Weinberger (1):
Uninclude linux/freezer.h
Diffstat:
arch/alpha/include/asm/thread_info.h |3 +-
arch/alpha/kernel/entry.S | 13 ++--
arch/alpha/kernel/ptrace.c| 32 -
arch/arm/include/asm/thread_info.h|2 -
arch/arm/kernel/signal.c |1 -
arch/avr32/include/asm/thread_info.h | 18 ++---
arch/avr32/kernel/signal.c|1 -
arch/blackfin/include/asm/thread_info.h |4 -
arch/blackfin/kernel/signal.c |1 -
arch/c6x/Kconfig |1 +
arch/c6x/include/asm/processor.h |2 -
arch/c6x/include/asm/syscalls.h |5 --
arch/c6x/include/asm/thread_info.h|1 -
arch/c6x/include/asm/unistd.h |3 +
arch/c6x/kernel/asm-offsets.c |1 -
arch/c6x/kernel/entry.S | 56 +++
arch/c6x/kernel/process.c
Re: [git pull] signal.git, pile 2 (was Re: [RFC][CFT][CFReview] execve and kernel_thread unification work)
On Fri, Oct 12, 2012 at 02:09:58AM +0100, Al Viro wrote: How granular are you planning to make that? I mean, we are talking about 3 objects here - init/main.o, kernel/kthread.o and kernel/kmod.o. Do they get TOC separate from that of arch/powerpc/kernel/entry_64.o? Potentially, yes, it would be up to the linker. Anyway, if ppc folks can live with that stuff in its current form for now, Yes, we can. Paul. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][CFT][CFReview] execve and kernel_thread unification work
On Tue, Oct 09, 2012 at 03:48:16PM -0400, Chris Metcalf wrote: > On 10/1/2012 5:38 PM, Al Viro wrote: > > There's an interesting ongoing project around kernel_thread() and > > friends, including execve() variants. I really need help from architecture > > maintainers on that one; I'd been able to handle (and test) quite a few > > architectures on my own [alpha, arm, m68k, powerpc, s390, sparc, x86, um] > > plus two more untested [frv, mn10300]. c6x patches had been supplied by > > Mark Salter; everything else remains to be done. Right now it's at > > minus 1.2KLoC, quite a bit of that removed from asm glue and other black > > magic. > > I'll take a look at this for arch/tile this week. Thanks. FWIW, changes since the last posting: * untested conversion for cris added [me] * conversion for mips added [Ralf has done execve side, I've added kernel_thread() one] * conversion for parisc added [aka "Al has generated broken patches, jejb has tested and fixed that crap"] * arm64 conversion added [Catalin Marinas] IOW, right now we have * alpha, arm, arm64, c6x, m68k, mips, parisc, powerpc, s390, sparc, um, x86 - apparently over and done with (IOW, all old architectures except for itanic are converted by now) * avr32, blackfin, hexagon, h8300, ia64, m32r, microblaze, openrisc, score, sh, tile, unicore32, xtensa - need to be done * cris, frv, mn10300 - need to be tested (and very likely will need fixing) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][CFT][CFReview] execve and kernel_thread unification work
On 10/1/2012 5:38 PM, Al Viro wrote: > There's an interesting ongoing project around kernel_thread() and > friends, including execve() variants. I really need help from architecture > maintainers on that one; I'd been able to handle (and test) quite a few > architectures on my own [alpha, arm, m68k, powerpc, s390, sparc, x86, um] > plus two more untested [frv, mn10300]. c6x patches had been supplied by > Mark Salter; everything else remains to be done. Right now it's at > minus 1.2KLoC, quite a bit of that removed from asm glue and other black > magic. I'll take a look at this for arch/tile this week. -- Chris Metcalf, Tilera Corp. http://www.tilera.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][CFT][CFReview] execve and kernel_thread unification work
On 10/1/2012 5:38 PM, Al Viro wrote: There's an interesting ongoing project around kernel_thread() and friends, including execve() variants. I really need help from architecture maintainers on that one; I'd been able to handle (and test) quite a few architectures on my own [alpha, arm, m68k, powerpc, s390, sparc, x86, um] plus two more untested [frv, mn10300]. c6x patches had been supplied by Mark Salter; everything else remains to be done. Right now it's at minus 1.2KLoC, quite a bit of that removed from asm glue and other black magic. I'll take a look at this for arch/tile this week. -- Chris Metcalf, Tilera Corp. http://www.tilera.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][CFT][CFReview] execve and kernel_thread unification work
On Tue, Oct 09, 2012 at 03:48:16PM -0400, Chris Metcalf wrote: On 10/1/2012 5:38 PM, Al Viro wrote: There's an interesting ongoing project around kernel_thread() and friends, including execve() variants. I really need help from architecture maintainers on that one; I'd been able to handle (and test) quite a few architectures on my own [alpha, arm, m68k, powerpc, s390, sparc, x86, um] plus two more untested [frv, mn10300]. c6x patches had been supplied by Mark Salter; everything else remains to be done. Right now it's at minus 1.2KLoC, quite a bit of that removed from asm glue and other black magic. I'll take a look at this for arch/tile this week. Thanks. FWIW, changes since the last posting: * untested conversion for cris added [me] * conversion for mips added [Ralf has done execve side, I've added kernel_thread() one] * conversion for parisc added [aka Al has generated broken patches, jejb has tested and fixed that crap] * arm64 conversion added [Catalin Marinas] IOW, right now we have * alpha, arm, arm64, c6x, m68k, mips, parisc, powerpc, s390, sparc, um, x86 - apparently over and done with (IOW, all old architectures except for itanic are converted by now) * avr32, blackfin, hexagon, h8300, ia64, m32r, microblaze, openrisc, score, sh, tile, unicore32, xtensa - need to be done * cris, frv, mn10300 - need to be tested (and very likely will need fixing) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][CFT][CFReview] execve and kernel_thread unification work
On Fri, Oct 05, 2012 at 05:07:47PM +0100, Catalin Marinas wrote: > Al, > > On 1 October 2012 22:38, Al Viro wrote: > > Right now the tree lives in > > git.kernel.org/pub/scm/linux/kernel/git/viro/signal > > experimental-kernel_thread > > Some of that had been in -next for a while. > > > > Folks, help with review, testing and filling the missing bits, > > please. > > I tested this branch with the arm64 kernel and runs ok (I get couple > of compiler warnings because reparent_to_kthread and > __set_special_pids are no longer used with the removal of daemonize). Applied and pushed. Also there - folded fixes from jejb into parisc part, optimizations of the fork-related paths in parisc on top of that (completely untested), fixed the sparc64 breakage davem had spotted yesterday. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][CFT][CFReview] execve and kernel_thread unification work
On Fri, Oct 05, 2012 at 05:07:47PM +0100, Catalin Marinas wrote: Al, On 1 October 2012 22:38, Al Viro v...@zeniv.linux.org.uk wrote: Right now the tree lives in git.kernel.org/pub/scm/linux/kernel/git/viro/signal experimental-kernel_thread Some of that had been in -next for a while. Folks, help with review, testing and filling the missing bits, please. I tested this branch with the arm64 kernel and runs ok (I get couple of compiler warnings because reparent_to_kthread and __set_special_pids are no longer used with the removal of daemonize). Applied and pushed. Also there - folded fixes from jejb into parisc part, optimizations of the fork-related paths in parisc on top of that (completely untested), fixed the sparc64 breakage davem had spotted yesterday. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][CFT][CFReview] execve and kernel_thread unification work
Al, On 1 October 2012 22:38, Al Viro wrote: > Right now the tree lives in > git.kernel.org/pub/scm/linux/kernel/git/viro/signal experimental-kernel_thread > Some of that had been in -next for a while. > > Folks, help with review, testing and filling the missing bits, please. I tested this branch with the arm64 kernel and runs ok (I get couple of compiler warnings because reparent_to_kthread and __set_special_pids are no longer used with the removal of daemonize). I have three arm64 patches on this branch: git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/linux-aarch64.git execve Catalin Marinas (3): arm64: Use generic kernel_thread() implementation arm64: Use generic kernel_execve() implementation arm64: Use generic sys_execve() implementation arch/arm64/Kconfig |1 + arch/arm64/include/asm/processor.h |5 -- arch/arm64/include/asm/syscalls.h |3 - arch/arm64/include/asm/unistd.h|3 + arch/arm64/kernel/entry.S | 28 ++--- arch/arm64/kernel/process.c| 78 +++ arch/arm64/kernel/sys.c| 65 -- arch/arm64/kernel/sys32.S |7 +--- arch/arm64/kernel/sys_compat.c | 18 9 files changed, 52 insertions(+), 156 deletions(-) -- Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][CFT][CFReview] execve and kernel_thread unification work
Al, On 1 October 2012 22:38, Al Viro v...@zeniv.linux.org.uk wrote: Right now the tree lives in git.kernel.org/pub/scm/linux/kernel/git/viro/signal experimental-kernel_thread Some of that had been in -next for a while. Folks, help with review, testing and filling the missing bits, please. I tested this branch with the arm64 kernel and runs ok (I get couple of compiler warnings because reparent_to_kthread and __set_special_pids are no longer used with the removal of daemonize). I have three arm64 patches on this branch: git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/linux-aarch64.git execve Catalin Marinas (3): arm64: Use generic kernel_thread() implementation arm64: Use generic kernel_execve() implementation arm64: Use generic sys_execve() implementation arch/arm64/Kconfig |1 + arch/arm64/include/asm/processor.h |5 -- arch/arm64/include/asm/syscalls.h |3 - arch/arm64/include/asm/unistd.h|3 + arch/arm64/kernel/entry.S | 28 ++--- arch/arm64/kernel/process.c| 78 +++ arch/arm64/kernel/sys.c| 65 -- arch/arm64/kernel/sys32.S |7 +--- arch/arm64/kernel/sys_compat.c | 18 9 files changed, 52 insertions(+), 156 deletions(-) -- Catalin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
