[PATCH 128] introduce suppress_sigtrap() to prevent unwanted send_sigtrap()

[Oleg Nesterov]

On 11/04, Roland McGrath wrote:
>
> > In this case the tracee resumes and stops after syscall_trace_leave()
> > to report PTRACE_EVENT_FORK, but since it passes syscall_trace_leave()
> > with TIF_SINGLESTEP set the tracee gets the unwanted send_sigtrap().
> >
> > Note: of course, this is hack. I think this should be move to utrace
> > layer. Unless we are going to call finish_resume_report(), finish_report()
> > should look at report->action and clear TIF_SINGLESTEP when needed.
>
> I thought we had just covered this before.

Let's return to this patch.

I don't understand how the discussed changes in syscall_trace_leave() path
can make any difference here.

Once again.

	The PTRACE_O_TRACEFORK tracee calls fork(), stops in SYSCALL_ENTRY.

	The tracer does PTRACE_SINGLESTEP. utrace_control(UTRACE_SINGLESTEP)
	sets TIF_SINGLESTEP.

	The tracee resumes, it must report PTRACE_EVENT_FORK. But, unlike
	upstream, we don't stop inside do_fork(), the tracee will stop
	in utrace_resume(). Before that, it passes syscall_trace_leave(),
	and since TIF_SINGLESTEP is set the tracee gets SIGTRAP.

Perhaps you meant utrace-cleanup branch? In this case ptrace_report_clone()
doesn't need suppress_sigtrap(), because utrace_control(UTRACE_SINGLESTEP)
will not set TIF_SINGLESTEP.

But what about other users, ptrace_report_syscall_entry(PTRACE_O_SYSEMU) and
ptrace_report_exec(PTRACE_O_TRACEEXEC) ? Don't they need suppress_sigtrap()
anyway?

Consider:

	the tracee is going to call exec(), it is stopped right before
	syscall insn.

	the tracer does PTRACE_SINGLESTEP.

	the tracee returns to user mode and enters syscall with
	TIF_SINGLESTEP set.

	ptrace_report_exec() returns UTRACE_STOP, but again, it stops
	in utrace_resume() after syscall_trace_leave() has already
	sent SIGTRAP.

Confused.

Oleg.