On 07/22, Oleg Nesterov wrote: > > (change subject) (really change the subject)
On 07/21, Roland McGrath wrote: > > > The usage of ->ptrace in utrace-ptrace is racy [...] > > Sure. Replace it. I'm not sure what purpose ->ptrace (or ctx->flags) > serves for attach/detach. You need somewhere to store the > PTRACE_SETOPTIONS state and so forth, sure. But you can probably just > handle the attachedness at the utrace level. That's what > UTRACE_ATTACH_EXCLUSIVE is for. Yes. As for ->ptrace, I think it should die. The only problem is PT_PTRACED bit. It would be nice to move it into ->utrace_flags, but this needs some not-very-nice changes. > > I think we need another variable which should be used instead, and > > the only "good" place where it can live is engine->data, it should > > point to "struct ptrace_xxx". > > Of course! That was the main point of the whole ptrace-tracee data > structure cleanup. Yes, yes, I see. But there is a problem. Which I didn't expect at all. Who will kfree() engine->data ? sys_ptrace(PTRACE_DETACH) can do this. But what if the tracer exits and detaches? Or release_task() does untrace. Yes, we can use task_struct->ptrace_ctx which is freed by free_task(), in this case engine->data == child->ptrace_ctx. But imho this would be very bad. OTOH, perhaps we can't avoid task_struct->ptrace_ctx. Otherwise, it is not easy to move task_struct->parent into ptrace_context. Oleg.
