force_successful_syscall_return() buggy?
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 10 lines · David S. Miller
Quoted 2 lines · Russell King
I'm not actually talking about subsequent syscalls issued by the kernel. I'm talking about stuff like init, bash, and the module tools.
Wrong, after the go for the first time into user space, the next trap into the kernel will put the
pt_regsat the top at the stack where we expect it to be.
I was facing a simillar problem with ptrace on Alpha (ptrace on alpha expect the pt_regs at current + 2*PAGE_SIZE for 2.4. kernel ) w.r.t www.openssi.org project. What i found was that even after we return to user space subsequent syscalls are not putting pt_regs at that offset. I guess while entering the kernel kernel stack pointer always point to value stored in thread_struct.ksp ?
-aneesh
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line · Aneesh Kumar K.V
Aneesh> I was facing a simillar problem with ptrace on Alpha (ptrace Aneesh> on alpha expect the pt_regs at current + 2*PAGE_SIZE for Aneesh> 2.4. kernel ) w.r.t www.openssi.org project. What i found Aneesh> was that even after we return to user space subsequent Aneesh> syscalls are not putting pt_regs at that offset. I guess Aneesh> while entering the kernel kernel stack pointer always point Aneesh> to value stored in thread_struct.ksp ?
If a platform doesn't start with an empty kernel stack on entry from user-space, that platform will be wasting (precious) stack space and ptrace() most likely won't work reliably. Personally, I'd consider such behavior a bug, but I suppose it is to some degree a platform-choice.
--david
From: David Mosberger <[email protected]>
Date: Tue, 17 Jun 2003 12:01:12 -0700
Personally, I'd consider such behavior a bug,
Me too.
Quoted 8 lines · David Mosberger
Aneesh> I was facing a simillar problem with ptrace on Alpha (ptrace Aneesh> on alpha expect the
pt_regsat current + 2*PAGE_SIZE for Aneesh> 2.4. kernel ) w.r.t www.openssi.org project. What i found Aneesh> was that even after we return to user space subsequent Aneesh> syscalls are not puttingpt_regsat that offset. I guess Aneesh> while entering the kernel kernel stack pointer always point Aneesh> to value stored in thread_struct.ksp ?
Quoted 4 lines
If a platform doesn't start with an empty kernel stack on entry from user-space, that platform will be wasting (precious) stack space and
ptrace()most likely won't work reliably. Personally, I'd consider such behavior a bug...
So would I. It's now fixed.
r~