Re: Q: UTRACE_SYSCALL_RESUMED logic

[Roland McGrath]

 On 11/18, Roland McGrath wrote:
 
   In any case, what is the rationality?
 
  The rationale is that if you see utrace_resume_action(action)==UTRACE_STOP
  in your callback, then you know another engine asked for stop
 
 Yes, but engine can't know if the next one is going to return
 UTRACE_STOP.

You can't know if the next one is going to change the registers and resume,
either.  That's just the general engine order issue.  The only point of
UTRACE_SYSCALL_RESUMED is to bring make it as possible to cooperate with a
stop-modify-resume engine as it already is with a modify-in-callback engine.

 OK, thanks. But shouldn't utrace_report_syscall_entry() reset
 report-action = UTRACE_RESUME after do_report_syscall_entry()?
 If we stop, report-action remains UTRACE_STOP when we do the
 reporting loop.

Yes, fixed.

 It is not clear to me why ptrace_report_syscall_entry() uses
 utrace_syscall_action() under if (UTRACE_SYSCALL_RESUMED).

That is what a callback should do if it doesn't have a specific intent.
Otherwise you clobber the choice made by a previous engine.

 This looks a bit strange because it returns the unconditional
 UTRACE_SYSCALL_RUN below. IOW, if ptrace should obey to another
 engine's request to abort this syscall, the code should use
 utrace_syscall_action() consistently.

Yes, it should not change the incoming action for a ptrace syscall report.

 OTOH, PTRACE_O_SYSEMU always aborts. Not sure I understand how
 different engines can be friendly to each other.

The friendly idea can only apply when an engine intends to be noninvasive
to userland behavior.  i.e., as the lone engine you would not perturb the
default behavior, so as a second engine you should not perturb what the
last engine chose.  When the ptrace engine is doing SYSEMU, it intends to
break the normal userland behavior.  There is just inherently no way to be
noninvasive about it.


Thanks,
Roland

Q: UTRACE_SYSCALL_RESUMED logic

[Oleg Nesterov]

Just can't understand UTRACE_SYSCALL_RESUMED code.

To the pointed, I tried to read the docs:

* When %UTRACE_STOP is used in @report_syscall_entry, then @task
* stops before attempting the system call.  In this case, another
* @report_syscall_entry callback follows after @task resumes;

Probably I misread this comment, or code (or both) but this is not
what utrace_report_syscall_entry().

The second reporting loop is done if the tracee stops, and its
-resume = UTRACE_REPORT after wakeup.

This can happen if, during the first report, one engine returns
UTRACE_STOP and another engine returns UTRACE_REPORT.

Or, no matter how many engines we have, the tracer uses UTRACE_REPORT
to wakeup the tracee after SYSCALL_ENTRY stop.

In any case, what is the rationality?

And how can we trust if (utrace-resume == UTRACE_REPORT) ?
If we have multiple engines, some engine can use UTRACE_INTERRUPT ?

Oleg.