Add FUTEX_CMP_REQUEUE futex op
A message that is not in the archive (sent off-list or not yet received): [email protected]
arch/s390/kernel/compat_wrapper.S line 1104
Quoted 11 lines · On Mon, 7 Jun 2004 18:03:49 +0200 Martin Schwidefsky <[email protected]>…
arch/s390/kernel/compat_wrapper.S +2
-0@@ -1097,6 +1097,8 @@ lgfr %r4,%r4 # int llgtr %r5,%r5 # struct compat_timespec * llgtr %r6,%r6 # u32 * + lgf %r0,164(%r15) # int + stg %r0,160(%r15) jg compat_sys_futex # branch to system call .globl sys32_setxattr_wrapper
Is it just me, or this could he above stand a use of STACK_FRAME_OVERHEAD instead of 160? I envision a time when Ulrich Weigand comes out with a gcc -fkernel, and at that time we'll need all such references configurable.
include/asm-s390/ptrace.h line 307
Quoted 9 lines
diff -urN
linux-2.6/include/asm-s390/ptrace.hlinux-2.6-s390/include/asm-s390/ptrace.hinclude/asm-s390/ptrace.h +1
-0@@ -303,6 +303,7 @@*/ struct pt_regs { +unsigned long args[1 ];psw_t psw;
This worries me, together with
(__u32*)((addr_t) &__KSTK_PTREGS(child)->psw
Why not to place the necessary word outside of the struct? It just logically doesn't belong. Might be just as easy to do that mvc to other place.
I think I'll try to scope such an implemenation.
-- Pete
Quoted 4 lines · Pete Zaitcev
Is it just me, or this could he above stand a use of
STACK_FRAME_OVERHEADinstead of 160? I envision a time when Ulrich Weigand comes out with a gcc -fkernel, and at that time we'll need all such references configurable.
It wouldn't hurt, but even if we get -mkernel support in gcc, that doesn't mean that the stack frame size has to change: You can easily have %r15 point to 160 bytes above the register save area without actually using all that space for saving registers. The only thing that would need to change is the location of the backchain pointer.
Quoted 3 lines
Why not to place the necessary word outside of the struct? It just logically doesn't belong. Might be just as easy to do that mvc to other place.
That actually was what Martin tried in his first implementation (well, the last one before the one he submitted). It didn't work out because some code relied on the stack starting right after pt_regs. Martin can probably clarify that on Friday.
Arnd <><
Quoted 5 lines
Quoted 5 lines
---
linux-2.6/arch/s390/kernel/compat_wrapper.SMon Jun 7
16:07:24 2004
Quoted 1 line
Quoted 1 line
+++
linux-2.6-s390/arch/s390/kernel/compat_wrapper.SMon Jun
7 16:07:53 2004
Quoted 3 lines
Review line 1098
Quoted 3 lines
(quoted diff) +0
-0@@ -1097,6 +1097,8 @@ lgfr %r4,%r4 # int llgtr %r5,%r5 #
struct compat_timespec *
Quoted 1 line
Review line 1099
Quoted 1 line
(quoted diff) +0
-0llgtr %r6,%r6 #
u32 *
Quoted 10 lines
Review line 1104
Quoted 5 lines
(quoted diff) +2
-0+ lgf %r0,164(%r15) # int + stg %r0,160(%r15) jg compat_sys_futex # branch to system call .globl sys32_setxattr_wrapperIs it just me, or this could he above stand a use of
STACK_FRAME_OVERHEADinstead of 160? I envision a time when Ulrich Weigand comes out with a gcc -fkernel, and at that time we'll need all such references configurable.
No, the offset of the arguments > 5 on the stack is 96 bytes on 31 bit and 160 bytes on 64 bit, period. This won't change because it is ABI relevant.
Quoted 13 lines
include/asm-s390/ptrace.h Mon Jun 7 16:07:53 2004 line 307
Quoted 9 lines
diff -urN
linux-2.6/include/asm-s390/ptrace.hlinux-2.6-s390/include/asm-s390/ptrace.hinclude/asm-s390/ptrace.h Mon Jun 7 16:07:53 2004 renamed from include/asm-s390/ptrace.h Mon May 10 04:32:54 2004 +1
-0@@ -303,6 +303,7 @@ */ struct pt_regs { + unsigned long args[1]; psw_t psw;This worries me, together with
(__u32*)((addr_t) &__KSTK_PTREGS(child)->psw
Quoted 3 lines
Why not to place the necessary word outside of the struct? It just logically doesn't belong. Might be just as easy to do that mvc to other place.
Well my first implementation had the arguments outside the pt_regs. But I came to the conclusion that this is wrong. First of all pt_regs is supposed to describe what is put on the stack during a system call and this includes the additional parameter. The second, more important thing is that without a structure describing exactly what's put on the stack it is impossible for lcrash or crash to decode the system entry stack frame. This is something we definitly want to have.
I though about the implications of the pt_regs changes for some time. Since the pt_regs structure is solely used to put the register on the kernel stack I don't see a problem. Every other structure is independent of it (at least in the 2.6 kernels).
blue skies,
Martin
Linux/390 Design & Development, IBM Deutschland Entwicklung GmbH Schönaicherstr. 220, D-71032 Böblingen, Telefon: 49 - (0)7031 - 16-2247
E-Mail: [email protected]