[PATCH] utrace: utrace_reset() should clear TIF_SINGLESTEP if no more engines

Oleg Nesterov oleg at redhat.com
Thu Sep 23 03:16:27 UTC 2010


On 09/21, Roland McGrath wrote:
>
> > OK, so what should we do for now?
>
> If we can't come to a straightforward answer for the general case
> fairly quickly, then we can do the simple change to start with.

I think we should start with changing utrace_control(DETACH) anyway,
then try to improve. I'll ressend the one-liner I already showed.

> > Without the multitracing utrace_resume()->user_disable_single_step()
> > fixes the problem. Otherwise we probably need ENGINE_WANTS_SINGLESTEP.
>
> No, no, we don't want that.  We don't need more state.  And, remember,
> we really don't need to microoptimize cases when single-step was used
> recently--the cost of taking one more single-step trap and percolating
> through the signal paths was going to be pretty large anyway.

OK,

> It's better to have a spurious report (preferably just spurious
> TIF_NOTIFY_RESUME with no actual callbacks) following any detach,
> or whatever it takes to ensure user_disable_single_step() always
> runs if user_enable_*_step did before and there is no engine around
> to see a report_quiesce callback pass.  If there is a report_quiesce
> or report_signal callback pass where nobody returns UTRACE_*STEP,
> then we should never leave stepping enabled when we return to user mode.

Hmm. I'll try to think more. Right now I don't really understand
how to do this correctly.

OK, finish_callback_report() and utrace_control(DETACH) can set
TIF_NOTIFY_RESUME. But what if there are no more attached engines?
Looks like, utrace_resume(UTRACE_RESUME) needs to handle this special
case. And utrace_reset() shouldn't clear task->utrace_flags, otherwise
utrace_resume/utrace_get_signal won't be called.

So, probably detach should set TIF_NOTIFY_RESUME, but utrace_reset()
should do user_disable_single_step() too if no more engines. Confused.

And in fact I don't understand why this is important. When it comes
to multiracing, any engine can hit the unwanted/unexpected trap
because another engine can ask for UTRACE_*STEP. The only really
important (I think) case is when the last engine detaches.

IOW. Suppose that eninge E does utrace_control(STEP) or its callback
returns UTRACE_*STEP. If we do not detach this engine, other engines
will see the trap. So why it is so important to clear X86_EFLAGS_TF
if we detach E ?

Oleg.




More information about the utrace-devel mailing list