Q: UTRACE_SYSCALL_RESUMED logic

[Oleg Nesterov]

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.

> and you can
> decide to return UTRACE_REPORT if you want to see the UTRACE_SYSCALL_RESUMED
> notification after the other engine resumes.  If you aren't delaying your
> consideration of the event until the UTRACE_SYSCALL_RESUMED case because
> you don't care, then you don't return UTRACE_REPORT and are not guaranteed
> the second report.

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.


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

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.

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

In short: should we remove this utrace_syscall_action() or should
we add another one instead? (I think the latter).

Oleg.