[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

[PATCH 42]



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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]