do_ptrace_notify_stop() doesn't change ->ptrace_message if the new
value is zero. Not sure what I was thinking about when I wrote this.
Remove the "ev->ev_message != 0" check. This is still wrong, I mean
this doesn't match the current behaviour.
task_struct->ptrace_message will die soon. But I don't understand
how compatible the new code should be wrt PTRACE_GETEVENTMSG.
Currently:
- ptrace_event() always sets ->ptrace_message, this is OK
- ptrace_report_syscall() and tracehook_signal_handler()
call ptrace_notify() directly which doesn't change
->ptrace_message, this means PTRACE_GETEVENTMSG reports
the previous value.
This looks a bit strange to me. Should we keep this
behaviour? Or can we return 0? Even better, we could
put somehing useful into ->ptrace_message, say, syscall
number.
- jctl stop doesn't change ->ptrace_message too. Again,
can the new code return 0?
This all is very minor, I am asking just in case.
---
kernel/ptrace.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- PU/kernel/ptrace.c~42_ZERO_PTRACE_MESSAGE 2009-09-16 15:04:48.000000000
+0200
+++ PU/kernel/ptrace.c 2009-09-16 15:08:28.000000000 +0200
@@ -956,8 +956,7 @@ static void do_ptrace_notify_stop(struct
{
struct ptrace_event *ev = ev_current(context);
- if (ev->ev_message)
- tracee->ptrace_message = ev->ev_message;
+ tracee->ptrace_message = ev->ev_message;
tracee->exit_code = ev->ev_code;
// XXX: for debug only
