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
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 <[email protected]>
Signed-off-by: Richard Henderson <[email protected]>
---
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
Signed-off-by: Richard Henderson <[email protected]>
---
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
Richard Henderson <[email protected]> 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 <[email protected]>
> Signed-off-by: Richard Henderson <[email protected]>
> ---
> 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
[email protected]
On Wed, Jul 30, 2014 at 11:42:32AM -1000, Richard Henderson wrote:
> Signed-off-by: Richard Henderson <[email protected]>
> ---
> 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.
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 <[email protected]>
>> ---
>> 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~
On 07/30/2014 12:04 PM, M?ns Rullg?rd wrote:
> Richard Henderson <[email protected]> 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~
Richard Henderson <[email protected]> writes:
> On 07/30/2014 12:04 PM, M?ns Rullg?rd wrote:
>> Richard Henderson <[email protected]> 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
[email protected]
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 <[email protected]>
> Signed-off-by: Richard Henderson <[email protected]>
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 <[email protected]>
Cheers
Michael.