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

Re: [PATCH 42] do_ptrace_notify_stop: kill "->ev_message != 0" check

> 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.

Perhaps you were thinking of the upstream code before tracehook.h was
introduced.  Ancient code left whatever was in ptrace_message before there
for the "0" cases.  When I made everything use ptrace_event(), the
semantics changed to yield 0 rather than last-event's-unrelated-value for
PTRACE_GETEVENTMSG after events that don't really have a message word.

> 	- 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.

I think we can set it to 0.  It's the same change we made by introducing
ptrace_event() for the other cases, and nobody complained.

> 	- jctl stop doesn't change ->ptrace_message too. Again,
> 	  can the new code return 0?

I think so.

> This all is very minor, I am asking just in case.

Right, diligence appreciated!  It might be wisest to send the trivial
changes to clear ptrace_message in those cases upstream first so that we
match the semantics exactly.


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