On 08/10, Roland McGrath wrote: > > > Anyway. I am not proud of this idea, and it needs more thinking in any case. > > I don't doubt that we can find a set of rules by which it can work. But > IMHO it's far better to keep it a very simple API rule that ->data belongs > entirely to the engine but no other field should be touched directly. > Of course, ptrace can always be a behind-the-curtain exception. > But whenever we can avoid that, we will.
Agreed, but > Here's another idea. Don't ever leave the regular ptrace_ops engine > attached after PTRACE_DETACH. Instead, add another engine with a separate > ops vector and event mask, just for the parting signal case. That engine > is very simple: it only has to set UTRACE_EVENT(QUIESCE) implement the > callbacks to inject the parting signal (and handle the corner cases). I don't understand why this is better than just changing ->ops. Except, yes, I agree with above. Adding another engine during detach adds more complexity, UTRACE_ATTACH_CREATE can fail, we should create the new context for new_engine->data... But OK. Let's discuss this later. At least we both agree ptrace_attach() should not try to re-use the old engine, and detach should use a special ops vector (with old or new engine). This makes me feel a bit better. > > Other problems with attach/detach which are more or less simple: > > It sounds like you have fixes in mind. Just do them. OK, will do. > > 5. ptrace_report_clone() is racy. parent->parent can exit and untrace > > child before utrace_attach_task(child, UTRACE_ATTACH_CREATE ...). > > This seems like it would only matter if we lack proper synchronization > with whatever governs the tracer's list of tracees. Any of the kinds of > attach ought to take the appropriate lock for that, no? Can't understand... Just in case, I'll explain which race I meant. Suppose the freshly forked child should be ptraced. In that case ptrace_init_task(child) does ptrace_link() under write_lock(tasklist). Now ptrace_report_clone() should attach the ptrace_utrace_ops engine. But the tracer can exit and do ptrace_unlink(child) (in that case it also untraces current but this doesn't matter). If ptrace_report_clone() does ptrace_report_clone() after that, the child is not ptraced, but has ptrace_utrace_ops attached. > We have the ptrace-tests suite for lots of behavior semantics tests. > Run its 'make check' and see what pops out, and that should give you > plenty to think about. OK. I'll try to do some trivial fixups first, so that it will be possible to actually run and test the kernel with ptrace-over-utrace. Oleg.