[PATCH 0/2] alpha updates

[PATCH 0/2] alpha updates

[Richard Henderson]

The first patch should fix the clone bug that Michael Cree reported.
The second patch adds the three new syscalls since the last update.

The tree can be found at

  git://github.com/rth7680/linux.git axp-next


r~


Richard Henderson (2):
  alpha: Remove "strange" OSF/1 fork semantics
  alpha: Add sched_set/getattr and renameat2 syscalls

 arch/alpha/include/asm/unistd.h      | 2 +-
 arch/alpha/include/uapi/asm/unistd.h | 3 +++
 arch/alpha/kernel/process.c          | 2 --
 arch/alpha/kernel/systbls.S          | 3 +++
 4 files changed, 7 insertions(+), 3 deletions(-)

-- 
1.9.3

[PATCH 1/2] alpha: Remove "strange" OSF/1 fork semantics

[Richard Henderson]

The assignment to regs->r20 kills the original tls_val input
to the clone syscall, which means that clone can no longer be
restarted with the original inputs.

We could, perhaps, retain this result for true fork, but OSF/1
compatibility is no longer important.  Note that glibc has never
used the r20 result value, instead always testing r0 vs 0 to
determine the child/parent status.

This failure can be seen in the glibc nptl/tst-eintr* tests.

Reported-by: Michael Cree <mcree@orcon.net.nz>
Signed-off-by: Richard Henderson <rth@twiddle.net>
---
 arch/alpha/kernel/process.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/alpha/kernel/process.c b/arch/alpha/kernel/process.c
index 1941a07..77028d7 100644
--- a/arch/alpha/kernel/process.c
+++ b/arch/alpha/kernel/process.c
@@ -278,8 +278,6 @@ copy_thread(unsigned long clone_flags, unsigned long usp,
 	*childregs = *regs;
 	childregs->r0 = 0;
 	childregs->r19 = 0;
-	childregs->r20 = 1;	/* OSF/1 has some strange fork() semantics.  */
-	regs->r20 = 0;
 	stack = ((struct switch_stack *) regs) - 1;
 	*childstack = *stack;
 	childstack->r26 = (unsigned long) ret_from_fork;
-- 
1.9.3

Re: [PATCH 1/2] alpha: Remove "strange" OSF/1 fork semantics

[Måns Rullgård]

Richard Henderson <rth@twiddle.net> writes:

> The assignment to regs->r20 kills the original tls_val input
> to the clone syscall, which means that clone can no longer be
> restarted with the original inputs.
>
> We could, perhaps, retain this result for true fork, but OSF/1
> compatibility is no longer important.  Note that glibc has never
> used the r20 result value, instead always testing r0 vs 0 to
> determine the child/parent status.

What effect does this have on OSF/1 compat?

> This failure can be seen in the glibc nptl/tst-eintr* tests.
>
> Reported-by: Michael Cree <mcree@orcon.net.nz>
> Signed-off-by: Richard Henderson <rth@twiddle.net>
> ---
>  arch/alpha/kernel/process.c | 2 --
>  1 file changed, 2 deletions(-)
>
> diff --git a/arch/alpha/kernel/process.c b/arch/alpha/kernel/process.c
> index 1941a07..77028d7 100644
> --- a/arch/alpha/kernel/process.c
> +++ b/arch/alpha/kernel/process.c
> @@ -278,8 +278,6 @@ copy_thread(unsigned long clone_flags, unsigned long usp,
>  	*childregs = *regs;
>  	childregs->r0 = 0;
>  	childregs->r19 = 0;
> -	childregs->r20 = 1;	/* OSF/1 has some strange fork() semantics.  */
> -	regs->r20 = 0;
>  	stack = ((struct switch_stack *) regs) - 1;
>  	*childstack = *stack;
>  	childstack->r26 = (unsigned long) ret_from_fork;
> -- 
> 1.9.3
>

-- 
Måns Rullgård
mans@mansr.com
--
To unsubscribe from this list: send the line "unsubscribe linux-alpha" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] alpha: Remove "strange" OSF/1 fork semantics

[Måns Rullgård]

Richard Henderson <rth@twiddle.net> writes:

> The assignment to regs->r20 kills the original tls_val input
> to the clone syscall, which means that clone can no longer be
> restarted with the original inputs.
>
> We could, perhaps, retain this result for true fork, but OSF/1
> compatibility is no longer important.  Note that glibc has never
> used the r20 result value, instead always testing r0 vs 0 to
> determine the child/parent status.

What effect does this have on OSF/1 compat?

> This failure can be seen in the glibc nptl/tst-eintr* tests.
>
> Reported-by: Michael Cree <mcree@orcon.net.nz>
> Signed-off-by: Richard Henderson <rth@twiddle.net>
> ---
>  arch/alpha/kernel/process.c | 2 --
>  1 file changed, 2 deletions(-)
>
> diff --git a/arch/alpha/kernel/process.c b/arch/alpha/kernel/process.c
> index 1941a07..77028d7 100644
> --- a/arch/alpha/kernel/process.c
> +++ b/arch/alpha/kernel/process.c
> @@ -278,8 +278,6 @@ copy_thread(unsigned long clone_flags, unsigned long usp,
>  	*childregs = *regs;
>  	childregs->r0 = 0;
>  	childregs->r19 = 0;
> -	childregs->r20 = 1;	/* OSF/1 has some strange fork() semantics.  */
> -	regs->r20 = 0;
>  	stack = ((struct switch_stack *) regs) - 1;
>  	*childstack = *stack;
>  	childstack->r26 = (unsigned long) ret_from_fork;
> -- 
> 1.9.3
>

-- 
Måns Rullgård
mans@mansr.com

Re: [PATCH 1/2] alpha: Remove "strange" OSF/1 fork semantics

[Richard Henderson]

On 07/30/2014 12:04 PM, Måns Rullgård wrote:
> Richard Henderson <rth@twiddle.net> writes:
> 
>> The assignment to regs->r20 kills the original tls_val input
>> to the clone syscall, which means that clone can no longer be
>> restarted with the original inputs.
>>
>> We could, perhaps, retain this result for true fork, but OSF/1
>> compatibility is no longer important.  Note that glibc has never
>> used the r20 result value, instead always testing r0 vs 0 to
>> determine the child/parent status.
> 
> What effect does this have on OSF/1 compat?

I don't know, as I've never had access to osf/1 myself.  It depends on how that
$20 value is used -- potentially, fork(3) no longer works.

I can imagine that we could retain these assignments under the condition of
clone_flags == 0, which both implies a basic fork as well as the fact that the
tls_val argument is unused.

But I do have to ask first if anyone actually cares.  Surely the amount of
osf-on-linux emulation is a vanishingly small proportion of the already small
alpha-linux population.


r~
--
To unsubscribe from this list: send the line "unsubscribe linux-alpha" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] alpha: Remove "strange" OSF/1 fork semantics

[Richard Henderson]

On 07/30/2014 12:04 PM, Måns Rullgård wrote:
> Richard Henderson <rth@twiddle.net> writes:
> 
>> The assignment to regs->r20 kills the original tls_val input
>> to the clone syscall, which means that clone can no longer be
>> restarted with the original inputs.
>>
>> We could, perhaps, retain this result for true fork, but OSF/1
>> compatibility is no longer important.  Note that glibc has never
>> used the r20 result value, instead always testing r0 vs 0 to
>> determine the child/parent status.
> 
> What effect does this have on OSF/1 compat?

I don't know, as I've never had access to osf/1 myself.  It depends on how that
$20 value is used -- potentially, fork(3) no longer works.

I can imagine that we could retain these assignments under the condition of
clone_flags == 0, which both implies a basic fork as well as the fact that the
tls_val argument is unused.

But I do have to ask first if anyone actually cares.  Surely the amount of
osf-on-linux emulation is a vanishingly small proportion of the already small
alpha-linux population.


r~

Re: [PATCH 1/2] alpha: Remove "strange" OSF/1 fork semantics

[Måns Rullgård]

Richard Henderson <rth@twiddle.net> writes:

> On 07/30/2014 12:04 PM, Måns Rullgård wrote:
>> Richard Henderson <rth@twiddle.net> writes:
>> 
>>> The assignment to regs->r20 kills the original tls_val input
>>> to the clone syscall, which means that clone can no longer be
>>> restarted with the original inputs.
>>>
>>> We could, perhaps, retain this result for true fork, but OSF/1
>>> compatibility is no longer important.  Note that glibc has never
>>> used the r20 result value, instead always testing r0 vs 0 to
>>> determine the child/parent status.
>> 
>> What effect does this have on OSF/1 compat?
>
> I don't know, as I've never had access to osf/1 myself.  It depends on
> how that $20 value is used -- potentially, fork(3) no longer works.

That would render the entire OSF/1 compat useless.

> I can imagine that we could retain these assignments under the
> condition of clone_flags == 0, which both implies a basic fork as well
> as the fact that the tls_val argument is unused.
>
> But I do have to ask first if anyone actually cares.  Surely the
> amount of osf-on-linux emulation is a vanishingly small proportion of
> the already small alpha-linux population.

I don't like the idea of breaking features without good reason.  It's
also not obvious to me that those who have reasons to run Alpha hardware
at all also don't have reasons to run OSF/1 binaries on it.

I have Alpha machines with both Linux and OSF/1 (Tru64), so I could run
some quick tests, though I'm not certain what would make a good test
case for this.

-- 
Måns Rullgård
mans@mansr.com
--
To unsubscribe from this list: send the line "unsubscribe linux-alpha" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] alpha: Remove "strange" OSF/1 fork semantics

[Måns Rullgård]

Richard Henderson <rth@twiddle.net> writes:

> On 07/30/2014 12:04 PM, Måns Rullgård wrote:
>> Richard Henderson <rth@twiddle.net> writes:
>> 
>>> The assignment to regs->r20 kills the original tls_val input
>>> to the clone syscall, which means that clone can no longer be
>>> restarted with the original inputs.
>>>
>>> We could, perhaps, retain this result for true fork, but OSF/1
>>> compatibility is no longer important.  Note that glibc has never
>>> used the r20 result value, instead always testing r0 vs 0 to
>>> determine the child/parent status.
>> 
>> What effect does this have on OSF/1 compat?
>
> I don't know, as I've never had access to osf/1 myself.  It depends on
> how that $20 value is used -- potentially, fork(3) no longer works.

That would render the entire OSF/1 compat useless.

> I can imagine that we could retain these assignments under the
> condition of clone_flags == 0, which both implies a basic fork as well
> as the fact that the tls_val argument is unused.
>
> But I do have to ask first if anyone actually cares.  Surely the
> amount of osf-on-linux emulation is a vanishingly small proportion of
> the already small alpha-linux population.

I don't like the idea of breaking features without good reason.  It's
also not obvious to me that those who have reasons to run Alpha hardware
at all also don't have reasons to run OSF/1 binaries on it.

I have Alpha machines with both Linux and OSF/1 (Tru64), so I could run
some quick tests, though I'm not certain what would make a good test
case for this.

-- 
Måns Rullgård
mans@mansr.com

Re: [PATCH 1/2] alpha: Remove "strange" OSF/1 fork semantics

[Michael Cree]

On Wed, Jul 30, 2014 at 11:42:31AM -1000, Richard Henderson wrote:
> The assignment to regs->r20 kills the original tls_val input
> to the clone syscall, which means that clone can no longer be
> restarted with the original inputs.
> 
> We could, perhaps, retain this result for true fork, but OSF/1
> compatibility is no longer important.  Note that glibc has never
> used the r20 result value, instead always testing r0 vs 0 to
> determine the child/parent status.
> 
> This failure can be seen in the glibc nptl/tst-eintr* tests.
> 
> Reported-by: Michael Cree <mcree@orcon.net.nz>
> Signed-off-by: Richard Henderson <rth@twiddle.net>

The glibc nptl/tst-eintr3 test now works successfully on the SMP
system with the patched kernel.

In addition builds of openjdk-6 or openjdk-7 use to always fail
because javac would randomly lock up at some point.  A test build of
openjdk-6 has just built successfully to completion with the patched
kernel.

I am not able to test whether OSF/1 compatibility is adversely
affected.

Tested-by: Michael Cree <mcree@orcon.net.nz>

Cheers
Michael.

[PATCH 2/2] alpha: Add sched_set/getattr and renameat2 syscalls

[Richard Henderson]

Signed-off-by: Richard Henderson <rth@twiddle.net>
---
 arch/alpha/include/asm/unistd.h      | 2 +-
 arch/alpha/include/uapi/asm/unistd.h | 3 +++
 arch/alpha/kernel/systbls.S          | 3 +++
 3 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/arch/alpha/include/asm/unistd.h b/arch/alpha/include/asm/unistd.h
index f2c9440..c509d30 100644
--- a/arch/alpha/include/asm/unistd.h
+++ b/arch/alpha/include/asm/unistd.h
@@ -3,7 +3,7 @@
 
 #include <uapi/asm/unistd.h>
 
-#define NR_SYSCALLS			508
+#define NR_SYSCALLS			511
 
 #define __ARCH_WANT_OLD_READDIR
 #define __ARCH_WANT_STAT64
diff --git a/arch/alpha/include/uapi/asm/unistd.h b/arch/alpha/include/uapi/asm/unistd.h
index 53ae7bb..d214a035 100644
--- a/arch/alpha/include/uapi/asm/unistd.h
+++ b/arch/alpha/include/uapi/asm/unistd.h
@@ -469,5 +469,8 @@
 #define __NR_process_vm_writev		505
 #define __NR_kcmp			506
 #define __NR_finit_module		507
+#define __NR_sched_setattr		508
+#define __NR_sched_getattr		509
+#define __NR_renameat2			510
 
 #endif /* _UAPI_ALPHA_UNISTD_H */
diff --git a/arch/alpha/kernel/systbls.S b/arch/alpha/kernel/systbls.S
index dca9b3f..2478971 100644
--- a/arch/alpha/kernel/systbls.S
+++ b/arch/alpha/kernel/systbls.S
@@ -526,6 +526,9 @@ sys_call_table:
 	.quad sys_process_vm_writev		/* 505 */
 	.quad sys_kcmp
 	.quad sys_finit_module
+	.quad sys_sched_setattr
+	.quad sys_sched_getattr
+	.quad sys_renameat2			/* 510 */
 
 	.size sys_call_table, . - sys_call_table
 	.type sys_call_table, @object
-- 
1.9.3

Re: [PATCH 2/2] alpha: Add sched_set/getattr and renameat2 syscalls

[Michael Cree]

On Wed, Jul 30, 2014 at 11:42:32AM -1000, Richard Henderson wrote:
> Signed-off-by: Richard Henderson <rth@twiddle.net>
> ---
>  arch/alpha/include/asm/unistd.h      | 2 +-
>  arch/alpha/include/uapi/asm/unistd.h | 3 +++
>  arch/alpha/kernel/systbls.S          | 3 +++
>  3 files changed, 7 insertions(+), 1 deletion(-)

I thought Matt had already sent my patch to do just that to Linus.

Cheers
Michael.

Re: [PATCH 2/2] alpha: Add sched_set/getattr and renameat2 syscalls

[Richard Henderson]

On 07/30/2014 12:21 PM, Michael Cree wrote:
> On Wed, Jul 30, 2014 at 11:42:32AM -1000, Richard Henderson wrote:
>> Signed-off-by: Richard Henderson <rth@twiddle.net>
>> ---
>>  arch/alpha/include/asm/unistd.h      | 2 +-
>>  arch/alpha/include/uapi/asm/unistd.h | 3 +++
>>  arch/alpha/kernel/systbls.S          | 3 +++
>>  3 files changed, 7 insertions(+), 1 deletion(-)
> 
> I thought Matt had already sent my patch to do just that to Linus.

Yes, I see now that he has.  Ignore my (exact) duplicate.


r~