On 12/13, Roland McGrath wrote: > > > Its not entirely clear why we can check pending_attach outside of the > > utrace->lock and not be racy. > > I think it can be racy sometimes but that does not matter. > Maybe Oleg can verify my logic here. If it's right, he can > add some comments to make it more clear. > > There is only a very limited sort of "timeliness" guarantee about > getting your callbacks after utrace_attach_task()+utrace_set_events(). > If you know somehow that the task was definitely still in TASK_STOPPED > or TASK_TRACED after utrace_attach_task() returned, then your engine > gets all possible callbacks starting from when it resumes. Otherwise, > you can use utrace_control() with UTRACE_REPORT to ask to get some > callback "pretty soon". The only callback events you are ever 100% > guaranteed about (after success return from utrace_set_events()) are for > DEATH and REAP, which have an unconditional lock-and-check before making > engine callbacks.
Yes, I think this is correct. It is fine to miss ->pending_attach == T, and in any case the new attacher can come right after the check, even if it was checked under utrace->lock. It is important that the tracee can't miss, say, UTRACE_REPORT request (as you already explained), and every time the tracee clears ->resume it calls splice_attaching(). > In the stopped cases, there are lots of locks and barriers and things > after resuming. (Oleg?) Every time the tracee resumes after TASK_TRACED it uses utrace->lock to synchronize with utrace_control/etc, it must see any changes. Oleg.