Suggested by Roland.
Change tracehook_report_syscall_exit() to look at step flag and send
the trap signal if needed.
This change affects ia64, microblaze, parisc, powerpc, sh. They pass
nonzero "step" argument to tracehook but since it was ignored the tracee
reports via ptrace_notify(), this is not right and not consistent.
- PTRACE_SETSIGINFO doesn't work
- if the tracer resumes the tracee with signr != 0 the new signal
is generated rather than delivering it
- If PT_TRACESYSGOOD is set the tracee reports the wrong exit_code
I don't have a powerpc machine, but I think this test-case should
see the difference:
#include <unistd.h>
#include <sys/ptrace.h>
#include <sys/wait.h>
#include <assert.h>
#include <stdio.h>
int main(void)
{
int pid, status;
if (!(pid = fork())) {
assert(ptrace(PTRACE_TRACEME) == 0);
kill(getpid(), SIGSTOP);
getppid();
return 0;
}
assert(pid == wait(&status));
assert(ptrace(PTRACE_SETOPTIONS, pid, 0, PTRACE_O_TRACESYSGOOD) == 0);
assert(ptrace(PTRACE_SYSCALL, pid, 0,0) == 0);
assert(pid == wait(&status));
assert(ptrace(PTRACE_SINGLESTEP, pid, 0,0) == 0);
assert(pid == wait(&status));
if (status == 0x57F)
return 0;
printf("kernel bug: status=%X shouldn't have 0x80\n", status);
return 1;
}
Signed-off-by: Oleg Nesterov <[email protected]>
Acked-by: Roland McGrath <[email protected]>
---
include/linux/tracehook.h | 7 +++++++
1 file changed, 7 insertions(+)
--- TH/include/linux/tracehook.h~3_TRACEHOOK_HANDLE_STEPPING 2009-11-10 01:03:22.000000000 +0100
+++ TH/include/linux/tracehook.h 2009-11-10 22:00:37.000000000 +0100
@@ -134,6 +134,13 @@ static inline __must_check int tracehook
*/
static inline void tracehook_report_syscall_exit(struct pt_regs *regs, int step)
{
+ if (step) {
+ siginfo_t info;
+ user_single_step_siginfo(current, regs, &info);
+ force_sig_info(SIGTRAP, &info, current);
+ return;
+ }
+
ptrace_report_syscall(regs);
}
On Thu, 12 Nov 2009 18:38:53 +0100
Oleg Nesterov <[email protected]> wrote:
> Change tracehook_report_syscall_exit() to look at step flag and send
> the trap signal if needed.
>
> This change affects ia64, microblaze, parisc, powerpc, sh. They pass
> nonzero "step" argument to tracehook but since it was ignored the tracee
> reports via ptrace_notify(), this is not right and not consistent.
This patch conflicts with utrace-core.patch a bit:
***************
*** 134,139 ****
*/
static inline void tracehook_report_syscall_exit(struct pt_regs *regs, int step)
{
ptrace_report_syscall(regs);
}
--- 140,147 ----
*/
static inline void tracehook_report_syscall_exit(struct pt_regs *regs, int step)
{
+ if (task_utrace_flags(current) & UTRACE_EVENT(SYSCALL_EXIT))
+ utrace_report_syscall_exit(regs);
ptrace_report_syscall(regs);
}
I did this:
static inline void tracehook_report_syscall_exit(struct pt_regs *regs, int step)
{
if (step) {
siginfo_t info;
user_single_step_siginfo(current, regs, &info);
force_sig_info(SIGTRAP, &info, current);
return;
}
+ if (task_utrace_flags(current) & UTRACE_EVENT(SYSCALL_EXIT))
+ utrace_report_syscall_exit(regs);
ptrace_report_syscall(regs);
}
utrace-core.patch is getting rather old. What is its status?
On 11/13, Andrew Morton wrote:
>
> On Thu, 12 Nov 2009 18:38:53 +0100
> Oleg Nesterov <[email protected]> wrote:
>
> > Change tracehook_report_syscall_exit() to look at step flag and send
> > the trap signal if needed.
> >
> > This change affects ia64, microblaze, parisc, powerpc, sh. They pass
> > nonzero "step" argument to tracehook but since it was ignored the tracee
> > reports via ptrace_notify(), this is not right and not consistent.
>
> This patch conflicts with utrace-core.patch a bit:
Ah, indeed, sorry...
> static inline void tracehook_report_syscall_exit(struct pt_regs *regs, int step)
> {
> if (step) {
> siginfo_t info;
> user_single_step_siginfo(current, regs, &info);
> force_sig_info(SIGTRAP, &info, current);
> return;
> }
>
> + if (task_utrace_flags(current) & UTRACE_EVENT(SYSCALL_EXIT))
> + utrace_report_syscall_exit(regs);
> ptrace_report_syscall(regs);
> }
>
>
> utrace-core.patch is getting rather old. What is its status?
Roland, given that you are going to send the updated utrace patch,
perhaps it makes sense to drop this old utrace-core.patch from -mm?
Oleg.
> Roland, given that you are going to send the updated utrace patch,
> perhaps it makes sense to drop this old utrace-core.patch from -mm?
Yes, I think that's the easiest thing to do. When we send new utrace and
ptrace code, we can make that relative to -mm or at least relative to the
all ptrace-related patches you've already submitted in this cycle.
Thanks,
Roland