> Not sure this makes real sense, but perhaps it would be tidier to > check QUIESCE in utrace_resume.
I think the theory was that getting there without it set would be very unlikely. That wasn't really true with the report-on-attach behavior. But it should be without that (read on). OTOH, the bit test is very cheap in comparison to even one pointless iteration of that loop, so no harm in a short-circuit check. However, I am not sure it is safe to jump around finish_resume_report(). I have been failing to come up with the exact scenario. But I'm concerned that missing user_disable_single_step() there could matter in some situation where UTRACE_SINGLESTEP was used before. > I wonder if we still have reasons to set ->report + TIF_NOTIFY_RESUME > in utrace_add_engine(). Looks like this is not needed now, but I am > not sure. There was never a reason to force a report soon after attach. What mattered is that start_report() sees ->report set and knows to take the lock and do splice_attaching() before the next reporting pass. There are no guarantees about actual races with a reporting pass that is starting asynchronously. But the attacher can know by external means that the attach finished before a traced event happened, e.g. it saw the tracee blocked in a syscall right after utrace_attach_task() returned, or an hour has passed since the attach. Please review commit 04852f3. I added a separate flag to guarantee start_report() notices pending attaches without using TIF_NOTIFY_RESUME. Thanks, Roland
