On 08/21, Srikar Dronamraju wrote: > > > Please note the comment, this check relies on UTRACE_ATTACH_EXCLUSIVE > > above. Once we see ->ptrace = 0 after utrace_attach_task(), nobody > > can change ->ptrace. > > However after attaching an engine exclusively, (which would mean the > child is not traced or was detached, or is about to be detached,) > we may still find ->ptrace to be non-NULL and detach the engine. > > Currently we do ptrace_detach_task() just before __ptrace_unlink(). Is > there any specific reason to do ptrace_detach_task() before > __ptrace_unlink()? Is it possible to have ptrace_detach_task() > which is not immediately followed by __ptrace_unlink()? > > If there is no such possibility then can we do ptrace_detach_task() > after __ptrace_unlink(). This could mean attaching an engine with > UTRACE_ATTACH_EXCLUSIVE flag set is enough to say ->ptrace = 0
Yes, and I thought about this. And please note that this patch makes sense anyway: if we change the order of detach (or when we finally kill task_struct->ptrace), we can just remove this single check in ptrace_attach_task(). In fact this was one of the reasons to make this patch. But. I am not sure yet detach can always __ptrace_unlink() first, and for the first version I am not going to do this change without strong reasons. Oleg.
