On 10/29, Roland McGrath wrote: > > Another example is E1 does UTRACE_BLOCKSTEP and then E2 > does UTRACE_SINGLESTEP. > > Now single-step will win out, which is right. But E2 gets no notice about > this, so it can't know that the step is for an insn rather than a block.
Yes. > In contrast, say utrace_control reduces both to UTRACE_REPORT, either > implicitly as we had been discussing before, or because E3 comes along > (before or after) and calls utrace_control(,,UTRACE_REPORT). Then E[123] > get report_quiesce(0) in their callback order. (We can't control that > order much today, but that is still to consolidate the utrace_control > ordering issue into that existing general ordering issue.) Yes, we can't control the callback order, and this means we have the same problem even without utrace_control(). Suppose that we enter utrace_resume(), E1->report_quiesce() returns UTRACE_BLOCKSTEP, then E2->report_quiesce() returns UTRACE_SINGLESTEP. UTRACE_SINGLESTEP wins, but E1 can't know about this. > > Yes, I hope I understand utrace.c ;) I meant user_enable_single_step(). > > I don't really understand it even in x86 case, to many low level magic. > > Ok, good. You officially don't need to understand that unless you want to. I want ;) Just every time I recall about enable_step/etc I have more prioritized pending problems. > > Afaics, we can kill ->stopped, but utrace_stop() and utrace_finish_jctl() > > should do unconditial spin_unlock_wait(utrace->lock) after resume (or > > lock/unlock). > > Ok. Please send a patch relative to utrace-cleanup with that code > including comments that explain those needs. OK, will do. Oleg.
