On 09/21, Roland McGrath wrote: > > > I was worried about the case when the TIF_SINGLESTEP tracee detaches > > itself and escapes finish_resume_report()->user_disable_single_step(), > > say, utrace_report_exec(). But probably we can ignore this. > > No, I think that is indeed a problem. If no engine is still attached > whose last callback returned UTRACE_SINGLESTEP, we should never return > to user mode with single-step enabled.
OK, so what should we do for now? Without the multitracing utrace_resume()->user_disable_single_step() fixes the problem. Otherwise we probably need ENGINE_WANTS_SINGLESTEP. > > Another concern was implicit detach, but thinking more I do not see > > why utrace_resume() is better. > > > > OK, I'll do some testing and resend right now. In UTRACE_DETACH case > > reset can be true but the tracee is running. But I don't think it > > makes sense to check target->exit_state == 0, correct? > > I think it's OK if it's running with ->exit_state set (or even with just > PF_EXITING set), i.e. already in kernel mode and never going back to > user mode. (Then it's essentially equivalent to calling user_*_step > while racing with a SIGKILL death, which has to be OK.) Any other kind > of running would not be OK. Yes, my concern was "running and !current", not "exiting". This is OK on x86 but user_disable_single_step() is arch specific. Oleg.
