> 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
