On 10/15, Roland McGrath wrote:
>
> > Not sure. Suppose we call utrace_control(old, UTRACE_DETACH) right
> > before the tracee utrace_get_signal() calls ops->report_signal().
>
> Then utrace_control() returns -EINPROGRESS.
It returns -EINPROGRESS if it sees ->reporting == engine.
But as I said, by the time utrace_control(DETACH) checks ->reporting it
can be already cleared by finish_callback().
> If it returned 0, then
> ops->report_signal will not be called. If that's not so, utrace_control
> is broken.
It will not be called, yes. But my point was, perhaps it was already
called and now we don't know whether we should deliver old->signr or
not.
> > utrace_control()->get_utrace_lock() succeeds, but when utrace_control()
> > checks ->reporting it could be already cleared.
>
> If it's already cleared then that means that ops->report_signal has
> returned and its return value has been processed.
Yes. but we can't know this. Or I missed something.
> > > If it fails, then the old engine's callback has
> > > run or is starting to run,
> >
> > Yes, and we can't know (afaics) whether UTRACE_SIGNAL_DELIVER was
> > already returned or not.
>
> I don't follow. If utrace_control returned zero, then any callback has
> returned whatever it was going to return before the detach takes effect.
See above. But here I was talking about the case when it doesn't return 0.
Anyway. I never claimed this can't work. Surely this all is solvable (and
probably even simpler than it seems to me). But I still think that re-using
is simpler, althought still can't prove this.
Perhaps I should make the patch which reimplements this code using
_detached_ops engine, so that we could compare...
> If that's not so, utrace_control is broken.
Well. perhaps finish_callback_report() should take utrace->lock when
it does
if (action == UTRACE_DETACH)
engine->ops = &utrace_detached_ops;
This way, afaics, utrace_control(DETACH) will be more "precise" wrt
returned value.
Again, again. I'd like to re-read this code (and utrace_barrier) later.
Right now I am trying to avoid thinking about anything except known problems
in utrace-ptrace ;)
Oleg.
