Q: ptrace_detach() && UTRACE_DETACH

[Oleg Nesterov]

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.