> I think we should start with changing utrace_control(DETACH) anyway, > then try to improve. I'll ressend the one-liner I already showed.
Ok. > Hmm. I'll try to think more. Right now I don't really understand > how to do this correctly. I wasn't immediately sure either. > OK, finish_callback_report() and utrace_control(DETACH) can set > TIF_NOTIFY_RESUME. Right. Those utrace_resume has the report.action==UTRACE_RESUME bail-out case. So either that would change or detach would also do UTRACE_REPORT. > 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. Right. Or else tracehook_notify_resume could call utrace_resume unconditionally, but I'm not at all sure that is not worse. The original theory was that it should always be OK to have some utrace_flags bits stay set when they are "stale", because any kind of reporting pass that got enabled would hit the report->spurious case and clean the state up synchronously when it's safe. > So, probably detach should set TIF_NOTIFY_RESUME, but utrace_reset() > should do user_disable_single_step() too if no more engines. Confused. If there are no more engines but the tracee is still running, we still shouldn't do it there because it still might not be entirely safe. If the tracee is not stopped, it's only safe to call in current. > 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. Right. An engine earlier in the list could swallow the signal so the next engines' callbacks didn't see it. But it doesn't know that some later engines didn't also ask for stepping. So there would have to be some understood convention between engines. For example, a later engine could see info->si_signo==SIGTRAP et al and act on that even when the incoming utrace_signal_action(action)==UTRACE_SIGNAL_IGN. Of course, that doesn't help a non-stepping engine that is earlier in the list to know that a later engine will be swallowing the signal. The original theory on this was that we'd one day stop overloading user signals for debugger-induced traps. In some past TODO lists and postings I referred to "extension events". The idea (in part) was that things like hardware stepping would generate a special new flavor of utrace event rather than a real signal that has to be intercepted. Then engines' callbacks would easily see that this was a debugging event induced by some engine and ignore it (or more likely, just never get any callback unless your engine registered interest in stepping). This would also address the case of asynchronous engine detach just after a trap has actually hit, where today the SIGTRAP is queued and then later won't be intercepted by a debugger, and instead kills the user process. But we don't have any of that now, and don't yet know if we will really pursue any big improvements at this API level. > The only really > important (I think) case is when the last engine detaches. That's the most important case, sure. But in any case that is not actually racy, we should avoid later spurious traps. > 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. That's only so if the tracee actually gets back to user mode before we have another reporting pass. > So why it is so important to clear X86_EFLAGS_TF if we detach E ? Perhaps I am worrying too much about it. The worst thing is if it could really get "stuck". But that shouldn't be possible if there are any engines at all, perhaps only any with UTRACE_EVENT(QUIESCE) set. Worst case, one spurious SIGTRAP will get to a report_signal pass, but nobody will return UTRACE_*STEP again, so there won't be another. (Of course, nobody will swallow that SIGTRAP and so it will terminate the process first anyway, but that's another problem.) What seems important is any "non-racy" scenarios. That is, where perhaps it wasn't properly stopped and E detached "asynchronously", but in practice the tracee was known to be otherwise blocked elsewhere or something, so the detach should have full effect before it returns to user mode. But that is just vague theory off hand. Thanks, Roland
