[PATCH 100-103] ptrace_resume cleanup/simplification

[Oleg Nesterov]

On 10/20, Roland McGrath wrote:
>
> These exist purely for UML.  So the real test cases are to use UML.
> To start with, make sure that check_sysemu() gets the same results
> as on the vanilla kernel.

If only I knew how to use UML...

OK, thanks. I'll try to test it later, along with gdb testsuite testing.

> There is no distinction in ptrace between the entry and exit reports.
> So this is implementation detail, not semantics.  The semantics say that
> the tracer sees only one stop per syscall insn, not two.

Yes, yes, I see. I used ENTRY/EXIT terms just to clarify what I mean.

> The other thing that is possibly relevant to the semantics is the
> interaction with syscall audit.  In the syscall entry path, we decide
> that the syscall will be skipped, then stop for the ptrace report.
> After resuming, we'll get to audit_syscall_entry and it will examine the
> register state as changed by ptrace before the resumption.  So that will
> claim something or other (chosen by the tracer) for audit, even though
> the syscall doesn't really happen.  Then we'll get to the syscall exit
> path, do audit_syscall_exit with the very same register state, and do
> nothing else.

Yes, thanks. With the patches I sent the tracee stops after both
audit_syscall_entry() and audit_syscall_exit() were already called.

If the tracer changes (say) ->orig_ax, this won't be visible to audit.

> Those audit calls seem pretty useless since they don't even really tell
> a lie chosen by the tracer--the audit log just sees the "not really
> made" syscall entry state followed by the "aborted" (-ENOSYS) exit
> state.  But it might be considered worthwhile upstream to keep this
> exactly as it was.

Oh. Then we should stop in utrace_report_syscall_entry() path and
we need the additional complications to handle SYSEMU_SINGLESTEP
correctly. Although these complications are straightforward.

Can't we ignore this difference for now?

> Right.  There is another possible wrinkle, though this probably doesn't
> matter.  If you used PTRACE_SYSEMU{,_SINGLESTEP} and got a syscall entry
> stop, then you can resume it with PTRACE_SYSCALL or PTRACE_SINGLESTEP
> instead.

Yes, please see the changelog for "[PATCH 105] PTRACE_SYSEMU_SINGLESTEP".

This looks simple simple. we can introduce PTRACE_EVENT_SYSEMU_SYSCALL,
then add the new "case" into ptrace_resume()->switch().

Oleg.