On 08/21, Oleg Nesterov wrote: > > 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.
Missed this part... Yes, but I think this is OK. If we find ->ptrace != 0 we can fail. The child is about to be detached, but it is still traced or we can pretend it was traced when we called attach. > > 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. And we seem to have strong reasons. Srikar, sorry I forgot to CC you. Hopefully you can read utrace-devel. Oleg.
