Re: [update] Re: new execve/kernel_thread design
Acked-by: Hirokazu Takata Al, many thanks for your great job. P.S. I'm struggling to reconstruct and repair my m32r test environment... -- Takata From: Al Viro Subject: Re: [update] Re: new execve/kernel_thread design Date: Fri, 07 Dec 2012 22:23:58 + > Current situation: > > * most of the architectures are OK - alpha arm arm64 c6x frv hexagon ia64 m68k > microblaze mips openrisc parisc sparc s390 tile um unicore32 x86 xtensa > > * powerpc *still* awaits an ACK from maintainers; no reports of any breakage > on linux-next and seems to be doing fine on my tests. > > * sh - still nothing from Paul; I'm going to assume that what we have in > linux-next is OK > > * mn10300 - untested, AFAIK > * avr32, blackfin, cris, h8300, score - maintainers seem to be MIA > * m32r - maintainer is not MIA, but I'm not sure if anyone, including > maintainer, has working m32r test boxen anymore... Anyway, not a word on > m32r patches in that pile. > > Folks, this is the final warning - I *will* send a pull request on the > stuff currently in linux-next as soon as the merge window opens. It had > been sitting there for a long time by now and you've all been Cc'd on > that thread all along. > -- 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: [update] Re: new execve/kernel_thread design
Acked-by: Hirokazu Takata tak...@linux-m32r.org Al, many thanks for your great job. P.S. I'm struggling to reconstruct and repair my m32r test environment... -- Takata From: Al Viro v...@zeniv.linux.org.uk Subject: Re: [update] Re: new execve/kernel_thread design Date: Fri, 07 Dec 2012 22:23:58 + Current situation: * most of the architectures are OK - alpha arm arm64 c6x frv hexagon ia64 m68k microblaze mips openrisc parisc sparc s390 tile um unicore32 x86 xtensa * powerpc *still* awaits an ACK from maintainers; no reports of any breakage on linux-next and seems to be doing fine on my tests. * sh - still nothing from Paul; I'm going to assume that what we have in linux-next is OK * mn10300 - untested, AFAIK * avr32, blackfin, cris, h8300, score - maintainers seem to be MIA * m32r - maintainer is not MIA, but I'm not sure if anyone, including maintainer, has working m32r test boxen anymore... Anyway, not a word on m32r patches in that pile. Folks, this is the final warning - I *will* send a pull request on the stuff currently in linux-next as soon as the merge window opens. It had been sitting there for a long time by now and you've all been Cc'd on that thread all along. -- 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: [update] Re: new execve/kernel_thread design
On 12/7/2012 5:23 PM, Al Viro wrote: > Current situation: > > * most of the architectures are OK - alpha arm arm64 c6x frv hexagon ia64 m68k > microblaze mips openrisc parisc sparc s390 tile um unicore32 x86 xtensa > > * powerpc *still* awaits an ACK from maintainers; no reports of any breakage > on linux-next and seems to be doing fine on my tests. > > * sh - still nothing from Paul; I'm going to assume that what we have in > linux-next is OK > > * mn10300 - untested, AFAIK > * avr32, blackfin, cris, h8300, score - maintainers seem to be MIA > * m32r - maintainer is not MIA, but I'm not sure if anyone, including > maintainer, has working m32r test boxen anymore... Anyway, not a word on > m32r patches in that pile. > > Folks, this is the final warning - I *will* send a pull request on the > stuff currently in linux-next as soon as the merge window opens. It had > been sitting there for a long time by now and you've all been Cc'd on > that thread all along. IMHO, Al has done a great job reaching out to the architecture maintainers with this round of changes. I think it should be a model for any kind of similar tree-wide work. -- 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: [update] Re: new execve/kernel_thread design
Current situation: * most of the architectures are OK - alpha arm arm64 c6x frv hexagon ia64 m68k microblaze mips openrisc parisc sparc s390 tile um unicore32 x86 xtensa * powerpc *still* awaits an ACK from maintainers; no reports of any breakage on linux-next and seems to be doing fine on my tests. * sh - still nothing from Paul; I'm going to assume that what we have in linux-next is OK * mn10300 - untested, AFAIK * avr32, blackfin, cris, h8300, score - maintainers seem to be MIA * m32r - maintainer is not MIA, but I'm not sure if anyone, including maintainer, has working m32r test boxen anymore... Anyway, not a word on m32r patches in that pile. Folks, this is the final warning - I *will* send a pull request on the stuff currently in linux-next as soon as the merge window opens. It had been sitting there for a long time by now and you've all been Cc'd on that thread all along. -- 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: [update] Re: new execve/kernel_thread design
Current situation: * most of the architectures are OK - alpha arm arm64 c6x frv hexagon ia64 m68k microblaze mips openrisc parisc sparc s390 tile um unicore32 x86 xtensa * powerpc *still* awaits an ACK from maintainers; no reports of any breakage on linux-next and seems to be doing fine on my tests. * sh - still nothing from Paul; I'm going to assume that what we have in linux-next is OK * mn10300 - untested, AFAIK * avr32, blackfin, cris, h8300, score - maintainers seem to be MIA * m32r - maintainer is not MIA, but I'm not sure if anyone, including maintainer, has working m32r test boxen anymore... Anyway, not a word on m32r patches in that pile. Folks, this is the final warning - I *will* send a pull request on the stuff currently in linux-next as soon as the merge window opens. It had been sitting there for a long time by now and you've all been Cc'd on that thread all along. -- 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: [update] Re: new execve/kernel_thread design
On 12/7/2012 5:23 PM, Al Viro wrote: Current situation: * most of the architectures are OK - alpha arm arm64 c6x frv hexagon ia64 m68k microblaze mips openrisc parisc sparc s390 tile um unicore32 x86 xtensa * powerpc *still* awaits an ACK from maintainers; no reports of any breakage on linux-next and seems to be doing fine on my tests. * sh - still nothing from Paul; I'm going to assume that what we have in linux-next is OK * mn10300 - untested, AFAIK * avr32, blackfin, cris, h8300, score - maintainers seem to be MIA * m32r - maintainer is not MIA, but I'm not sure if anyone, including maintainer, has working m32r test boxen anymore... Anyway, not a word on m32r patches in that pile. Folks, this is the final warning - I *will* send a pull request on the stuff currently in linux-next as soon as the merge window opens. It had been sitting there for a long time by now and you've all been Cc'd on that thread all along. IMHO, Al has done a great job reaching out to the architecture maintainers with this round of changes. I think it should be a model for any kind of similar tree-wide work. -- 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: [update] Re: new execve/kernel_thread design
On Mon, Oct 29, 2012 at 03:38:23PM +0100, Martin Schwidefsky wrote: > On Mon, 29 Oct 2012 13:25:21 + > Al Viro wrote: > > > On Mon, Oct 29, 2012 at 08:53:39AM +0100, Martin Schwidefsky wrote: > > > > > Oops, sorry. I tested this weeks ago but it seems I never wrote a mail to > > > indicate success. The current git kernel works just fine. > > > > "Current git" being what? Linus' tree? linux-next? signal.git#arch-s390? > > FWIW, the relevant diff against mainline is below, linux-next already > > contains it. > > git://git.kernel.org/pub/scm/linux/kernel/git/viro/signal arch-s390 > > against Linux 3.7-rc3 > > # uname -a > Linux r3545014 3.7.0-rc3-2-g95a96a7 #1 SMP Mon Oct 29 15:32:18 CET 2012 > s390x s390x s390x GNU/Linux > > works as it is. Feel free to add my Acked-By. Done and pushed, should propagate shortly. It's in no-rebase mode now. -- 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: [update] Re: new execve/kernel_thread design
On Mon, 29 Oct 2012 13:25:21 + Al Viro wrote: > On Mon, Oct 29, 2012 at 08:53:39AM +0100, Martin Schwidefsky wrote: > > > Oops, sorry. I tested this weeks ago but it seems I never wrote a mail to > > indicate success. The current git kernel works just fine. > > "Current git" being what? Linus' tree? linux-next? signal.git#arch-s390? > FWIW, the relevant diff against mainline is below, linux-next already > contains it. git://git.kernel.org/pub/scm/linux/kernel/git/viro/signal arch-s390 against Linux 3.7-rc3 # uname -a Linux r3545014 3.7.0-rc3-2-g95a96a7 #1 SMP Mon Oct 29 15:32:18 CET 2012 s390x s390x s390x GNU/Linux works as it is. Feel free to add my Acked-By. -- blue skies, Martin. "Reality continues to ruin my life." - Calvin. -- 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: [update] Re: new execve/kernel_thread design
On Mon, Oct 29, 2012 at 08:53:39AM +0100, Martin Schwidefsky wrote: > Oops, sorry. I tested this weeks ago but it seems I never wrote a mail to > indicate success. The current git kernel works just fine. "Current git" being what? Linus' tree? linux-next? signal.git#arch-s390? FWIW, the relevant diff against mainline is below, linux-next already contains it. diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig index 3f3d9ca..3cdc0f1 100644 --- a/arch/s390/Kconfig +++ b/arch/s390/Kconfig @@ -136,6 +136,7 @@ config S390 select KTIME_SCALAR if 32BIT select HAVE_ARCH_SECCOMP_FILTER select GENERIC_KERNEL_THREAD + select GENERIC_KERNEL_EXECVE select HAVE_MOD_ARCH_SPECIFIC select MODULES_USE_ELF_RELA diff --git a/arch/s390/include/asm/unistd.h b/arch/s390/include/asm/unistd.h index bbbae41..ccbcab7 100644 --- a/arch/s390/include/asm/unistd.h +++ b/arch/s390/include/asm/unistd.h @@ -54,7 +54,6 @@ # define __ARCH_WANT_COMPAT_SYS_RT_SIGSUSPEND # endif #define __ARCH_WANT_SYS_EXECVE -#define __ARCH_WANT_KERNEL_EXECVE /* * "Conditional" syscalls diff --git a/arch/s390/kernel/entry.S b/arch/s390/kernel/entry.S index ef46f66..aa8f2ba 100644 --- a/arch/s390/kernel/entry.S +++ b/arch/s390/kernel/entry.S @@ -330,40 +330,18 @@ ENTRY(ret_from_fork) la %r11,STACK_FRAME_OVERHEAD(%r15) l %r12,__LC_THREAD_INFO l %r13,__LC_SVC_NEW_PSW+4 - tm __PT_PSW+1(%r11),0x01 # forking a kernel thread ? - je 1f l %r1,BASED(.Lschedule_tail) basr%r14,%r1# call schedule_tail TRACE_IRQS_ON ssm __LC_SVC_NEW_PSW# reenable interrupts - j sysc_tracenogo - -1: # it's a kernel thread - st %r15,__PT_R15(%r11) # store stack pointer for new kthread - l %r1,BASED(.Lschedule_tail) - basr%r14,%r1# call schedule_tail - TRACE_IRQS_ON - ssm __LC_SVC_NEW_PSW# reenable interrupts - lm %r9,%r11,__PT_R9(%r11) # load gprs + tm __PT_PSW+1(%r11),0x01 # forking a kernel thread ? + jne sysc_tracenogo + # it's a kernel thread + lm %r9,%r10,__PT_R9(%r11) # load gprs ENTRY(kernel_thread_starter) la %r2,0(%r10) basr%r14,%r9 - la %r2,0 - br %r11# do_exit - -# -# kernel_execve function needs to deal with pt_regs that is not -# at the usual place -# -ENTRY(ret_from_kernel_execve) - ssm __LC_PGM_NEW_PSW# disable I/O and ext. interrupts - lr %r15,%r2 - lr %r11,%r2 - ahi %r15,-STACK_FRAME_OVERHEAD - xc __SF_BACKCHAIN(4,%r15),__SF_BACKCHAIN(%r15) - l %r12,__LC_THREAD_INFO - ssm __LC_SVC_NEW_PSW# reenable interrupts - j sysc_return + j sysc_tracenogo /* * Program check handler routine diff --git a/arch/s390/kernel/entry64.S b/arch/s390/kernel/entry64.S index 07d8de3..499e95e 100644 --- a/arch/s390/kernel/entry64.S +++ b/arch/s390/kernel/entry64.S @@ -352,33 +352,17 @@ sysc_tracenogo: ENTRY(ret_from_fork) la %r11,STACK_FRAME_OVERHEAD(%r15) lg %r12,__LC_THREAD_INFO - tm __PT_PSW+1(%r11),0x01 # forking a kernel thread ? - je 1f brasl %r14,schedule_tail TRACE_IRQS_ON ssm __LC_SVC_NEW_PSW# reenable interrupts - j sysc_tracenogo -1: # it's a kernel thread - stg %r15,__PT_R15(%r11) # store stack pointer for new kthread - brasl %r14,schedule_tail - TRACE_IRQS_ON - ssm __LC_SVC_NEW_PSW# reenable interrupts - lmg %r9,%r11,__PT_R9(%r11) # load gprs + tm __PT_PSW+1(%r11),0x01 # forking a kernel thread ? + jne sysc_tracenogo + # it's a kernel thread + lmg %r9,%r10,__PT_R9(%r11) # load gprs ENTRY(kernel_thread_starter) la %r2,0(%r10) basr%r14,%r9 - la %r2,0 - br %r11# do_exit - -ENTRY(ret_from_kernel_execve) - ssm __LC_PGM_NEW_PSW# disable I/O and ext. interrupts - lgr %r15,%r2 - lgr %r11,%r2 - aghi%r15,-STACK_FRAME_OVERHEAD - xc __SF_BACKCHAIN(8,%r15),__SF_BACKCHAIN(%r15) - lg %r12,__LC_THREAD_INFO - ssm __LC_SVC_NEW_PSW# reenable interrupts - j sysc_return + j sysc_tracenogo /* * Program check handler routine -- 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: [update] Re: new execve/kernel_thread design
On Fri, 26 Oct 2012 19:31:07 +0100 Al Viro wrote: > The situation got much better by now. More than a half of > architectures are done - alpha arm arm64 c6x hexagon ia64 m68k mips openrisc > parisc sparc tile um unicore32 and x86. > > Two more avait ACKs from maintainers - powerpc and s390. Should work, > AFAICS. Oops, sorry. I tested this weeks ago but it seems I never wrote a mail to indicate success. The current git kernel works just fine. -- blue skies, Martin. "Reality continues to ruin my life." - Calvin. -- 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: [update] Re: new execve/kernel_thread design
On Fri, 26 Oct 2012 19:31:07 +0100 Al Viro v...@zeniv.linux.org.uk wrote: The situation got much better by now. More than a half of architectures are done - alpha arm arm64 c6x hexagon ia64 m68k mips openrisc parisc sparc tile um unicore32 and x86. Two more avait ACKs from maintainers - powerpc and s390. Should work, AFAICS. Oops, sorry. I tested this weeks ago but it seems I never wrote a mail to indicate success. The current git kernel works just fine. -- blue skies, Martin. Reality continues to ruin my life. - Calvin. -- 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: [update] Re: new execve/kernel_thread design
On Mon, Oct 29, 2012 at 08:53:39AM +0100, Martin Schwidefsky wrote: Oops, sorry. I tested this weeks ago but it seems I never wrote a mail to indicate success. The current git kernel works just fine. Current git being what? Linus' tree? linux-next? signal.git#arch-s390? FWIW, the relevant diff against mainline is below, linux-next already contains it. diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig index 3f3d9ca..3cdc0f1 100644 --- a/arch/s390/Kconfig +++ b/arch/s390/Kconfig @@ -136,6 +136,7 @@ config S390 select KTIME_SCALAR if 32BIT select HAVE_ARCH_SECCOMP_FILTER select GENERIC_KERNEL_THREAD + select GENERIC_KERNEL_EXECVE select HAVE_MOD_ARCH_SPECIFIC select MODULES_USE_ELF_RELA diff --git a/arch/s390/include/asm/unistd.h b/arch/s390/include/asm/unistd.h index bbbae41..ccbcab7 100644 --- a/arch/s390/include/asm/unistd.h +++ b/arch/s390/include/asm/unistd.h @@ -54,7 +54,6 @@ # define __ARCH_WANT_COMPAT_SYS_RT_SIGSUSPEND # endif #define __ARCH_WANT_SYS_EXECVE -#define __ARCH_WANT_KERNEL_EXECVE /* * Conditional syscalls diff --git a/arch/s390/kernel/entry.S b/arch/s390/kernel/entry.S index ef46f66..aa8f2ba 100644 --- a/arch/s390/kernel/entry.S +++ b/arch/s390/kernel/entry.S @@ -330,40 +330,18 @@ ENTRY(ret_from_fork) la %r11,STACK_FRAME_OVERHEAD(%r15) l %r12,__LC_THREAD_INFO l %r13,__LC_SVC_NEW_PSW+4 - tm __PT_PSW+1(%r11),0x01 # forking a kernel thread ? - je 1f l %r1,BASED(.Lschedule_tail) basr%r14,%r1# call schedule_tail TRACE_IRQS_ON ssm __LC_SVC_NEW_PSW# reenable interrupts - j sysc_tracenogo - -1: # it's a kernel thread - st %r15,__PT_R15(%r11) # store stack pointer for new kthread - l %r1,BASED(.Lschedule_tail) - basr%r14,%r1# call schedule_tail - TRACE_IRQS_ON - ssm __LC_SVC_NEW_PSW# reenable interrupts - lm %r9,%r11,__PT_R9(%r11) # load gprs + tm __PT_PSW+1(%r11),0x01 # forking a kernel thread ? + jne sysc_tracenogo + # it's a kernel thread + lm %r9,%r10,__PT_R9(%r11) # load gprs ENTRY(kernel_thread_starter) la %r2,0(%r10) basr%r14,%r9 - la %r2,0 - br %r11# do_exit - -# -# kernel_execve function needs to deal with pt_regs that is not -# at the usual place -# -ENTRY(ret_from_kernel_execve) - ssm __LC_PGM_NEW_PSW# disable I/O and ext. interrupts - lr %r15,%r2 - lr %r11,%r2 - ahi %r15,-STACK_FRAME_OVERHEAD - xc __SF_BACKCHAIN(4,%r15),__SF_BACKCHAIN(%r15) - l %r12,__LC_THREAD_INFO - ssm __LC_SVC_NEW_PSW# reenable interrupts - j sysc_return + j sysc_tracenogo /* * Program check handler routine diff --git a/arch/s390/kernel/entry64.S b/arch/s390/kernel/entry64.S index 07d8de3..499e95e 100644 --- a/arch/s390/kernel/entry64.S +++ b/arch/s390/kernel/entry64.S @@ -352,33 +352,17 @@ sysc_tracenogo: ENTRY(ret_from_fork) la %r11,STACK_FRAME_OVERHEAD(%r15) lg %r12,__LC_THREAD_INFO - tm __PT_PSW+1(%r11),0x01 # forking a kernel thread ? - je 1f brasl %r14,schedule_tail TRACE_IRQS_ON ssm __LC_SVC_NEW_PSW# reenable interrupts - j sysc_tracenogo -1: # it's a kernel thread - stg %r15,__PT_R15(%r11) # store stack pointer for new kthread - brasl %r14,schedule_tail - TRACE_IRQS_ON - ssm __LC_SVC_NEW_PSW# reenable interrupts - lmg %r9,%r11,__PT_R9(%r11) # load gprs + tm __PT_PSW+1(%r11),0x01 # forking a kernel thread ? + jne sysc_tracenogo + # it's a kernel thread + lmg %r9,%r10,__PT_R9(%r11) # load gprs ENTRY(kernel_thread_starter) la %r2,0(%r10) basr%r14,%r9 - la %r2,0 - br %r11# do_exit - -ENTRY(ret_from_kernel_execve) - ssm __LC_PGM_NEW_PSW# disable I/O and ext. interrupts - lgr %r15,%r2 - lgr %r11,%r2 - aghi%r15,-STACK_FRAME_OVERHEAD - xc __SF_BACKCHAIN(8,%r15),__SF_BACKCHAIN(%r15) - lg %r12,__LC_THREAD_INFO - ssm __LC_SVC_NEW_PSW# reenable interrupts - j sysc_return + j sysc_tracenogo /* * Program check handler routine -- 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: [update] Re: new execve/kernel_thread design
On Mon, 29 Oct 2012 13:25:21 + Al Viro v...@zeniv.linux.org.uk wrote: On Mon, Oct 29, 2012 at 08:53:39AM +0100, Martin Schwidefsky wrote: Oops, sorry. I tested this weeks ago but it seems I never wrote a mail to indicate success. The current git kernel works just fine. Current git being what? Linus' tree? linux-next? signal.git#arch-s390? FWIW, the relevant diff against mainline is below, linux-next already contains it. git://git.kernel.org/pub/scm/linux/kernel/git/viro/signal arch-s390 against Linux 3.7-rc3 # uname -a Linux r3545014 3.7.0-rc3-2-g95a96a7 #1 SMP Mon Oct 29 15:32:18 CET 2012 s390x s390x s390x GNU/Linux works as it is. Feel free to add my Acked-By. -- blue skies, Martin. Reality continues to ruin my life. - Calvin. -- 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: [update] Re: new execve/kernel_thread design
On Mon, Oct 29, 2012 at 03:38:23PM +0100, Martin Schwidefsky wrote: On Mon, 29 Oct 2012 13:25:21 + Al Viro v...@zeniv.linux.org.uk wrote: On Mon, Oct 29, 2012 at 08:53:39AM +0100, Martin Schwidefsky wrote: Oops, sorry. I tested this weeks ago but it seems I never wrote a mail to indicate success. The current git kernel works just fine. Current git being what? Linus' tree? linux-next? signal.git#arch-s390? FWIW, the relevant diff against mainline is below, linux-next already contains it. git://git.kernel.org/pub/scm/linux/kernel/git/viro/signal arch-s390 against Linux 3.7-rc3 # uname -a Linux r3545014 3.7.0-rc3-2-g95a96a7 #1 SMP Mon Oct 29 15:32:18 CET 2012 s390x s390x s390x GNU/Linux works as it is. Feel free to add my Acked-By. Done and pushed, should propagate shortly. It's in no-rebase mode now. -- 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: [update] Re: new execve/kernel_thread design
On Fri, Oct 26, 2012 at 07:31:07PM +0100, Al Viro wrote:
> The situation got much better by now. More than a half of
> architectures are done - alpha arm arm64 c6x hexagon ia64 m68k mips openrisc
> parisc sparc tile um unicore32 and x86.
>
> Two more avait ACKs from maintainers - powerpc and s390. Should work,
> AFAICS.
>
> xtensa - Max was going to repost updated patches; waiting for that
> to happen, but essentially it's done and tested.
>
> microblaze - Michal was debugging kernel_execve side of it the last
> time I've heard from him...
>
> frv, mn10300 - dhowells was going to test those
>
> sh - Paul Mundt was going to test and send fixes
>
> avr32, blackfin, cris, h8300, m32r, score - no signs of life from
> maintainers. Folks, please show up and at least test the damn patchsets.
> Hell knows, they might even work - unicore32 one did, modulo trivial typo,
> to my deep surprise...
BTW, there's a tangentially related issue: several architectures have
very odd clone(2). Namely, blackfin, h8300, no-MMU microblaze and sh64 (==sh5)
silently ignore child_tidptr and parent_tidptr arguments. I.e. treat them
as NULL - or as if CLONE_PARENT_SETTID/CLONE_CHILD_SETTID/CLONE_CHILD_CLEARTID
were never set. With the patchset in the local part of queue it would be
trivial to switch to normal semantics; strictly speaking, it's an ABI change.
Somebody doing
n = 0x69696969;
if (clone(CLONE_PARENT_SETTID, 0, ) > 0) {
if (n != 0x69696969) {
printf("oh, shit, we are not on blackfin\n");
exit(-1);
}
}
would run into a user-visible behaviour change, but IMO that's in the realm
of testing for known architecture-dependent bugs and finding them fixed...
Opinions, vetoes? Should we preserve the current behaviour in this case?
I would obviously prefer to just go ahead and fix the sucker - the odds of
any actual software depending on that behaviour are pretty much nil.
Linus, does that cross the boundary between bug fix and ABI breakage?
Another curious thing happens on blackfin; there we subtract 12 from usp
when it's non-zero (zero == inherit the parent's usp, as always). No idea
why is that done; this one definitely has to be preserved, so I'm just
wondering about the reasons behind that oddity... Mike?
--
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: [update] Re: new execve/kernel_thread design
On Fri, Oct 26, 2012 at 07:31:07PM +0100, Al Viro wrote:
The situation got much better by now. More than a half of
architectures are done - alpha arm arm64 c6x hexagon ia64 m68k mips openrisc
parisc sparc tile um unicore32 and x86.
Two more avait ACKs from maintainers - powerpc and s390. Should work,
AFAICS.
xtensa - Max was going to repost updated patches; waiting for that
to happen, but essentially it's done and tested.
microblaze - Michal was debugging kernel_execve side of it the last
time I've heard from him...
frv, mn10300 - dhowells was going to test those
sh - Paul Mundt was going to test and send fixes
avr32, blackfin, cris, h8300, m32r, score - no signs of life from
maintainers. Folks, please show up and at least test the damn patchsets.
Hell knows, they might even work - unicore32 one did, modulo trivial typo,
to my deep surprise...
BTW, there's a tangentially related issue: several architectures have
very odd clone(2). Namely, blackfin, h8300, no-MMU microblaze and sh64 (==sh5)
silently ignore child_tidptr and parent_tidptr arguments. I.e. treat them
as NULL - or as if CLONE_PARENT_SETTID/CLONE_CHILD_SETTID/CLONE_CHILD_CLEARTID
were never set. With the patchset in the local part of queue it would be
trivial to switch to normal semantics; strictly speaking, it's an ABI change.
Somebody doing
n = 0x69696969;
if (clone(CLONE_PARENT_SETTID, 0, n) 0) {
if (n != 0x69696969) {
printf(oh, shit, we are not on blackfin\n);
exit(-1);
}
}
would run into a user-visible behaviour change, but IMO that's in the realm
of testing for known architecture-dependent bugs and finding them fixed...
Opinions, vetoes? Should we preserve the current behaviour in this case?
I would obviously prefer to just go ahead and fix the sucker - the odds of
any actual software depending on that behaviour are pretty much nil.
Linus, does that cross the boundary between bug fix and ABI breakage?
Another curious thing happens on blackfin; there we subtract 12 from usp
when it's non-zero (zero == inherit the parent's usp, as always). No idea
why is that done; this one definitely has to be preserved, so I'm just
wondering about the reasons behind that oddity... Mike?
--
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/
