Q: utrace_stop() && notification

[Oleg Nesterov]

On 07/21, Roland McGrath wrote:
>
> > So, if we do not want to add the special (and not-a-report) hooks
> > into engine->ops, then perhaps it makes sense to do
> [...]
>
> That is exactly the kludge

I fully agree with the "kludge" above.

> > So, perhaps we can just add engine->ops->notify_stopped() (or even [...]
>
> My main point was that we should look for an entirely different way to
> attack the problem.  If I thought this hook would only be used for
> ptrace, it might be fine.  (OTOH then it's not all that much better than
> the terrible ptrace-only kludge.)  But AFAICT we'd likely wind up with
> every other new utrace module that cares about doing synchronization
> with debugger threads needing to use this hook too.  That's why I want
> to talk about the general case in the utrace API, and not just ptrace.

Yes sure. That is why I tried to talk about utrace notifications
"in general", not only about ptrace case.

> Let's ignore SIGCHLD for a moment, and just think about ptrace's
> report_* waking up wait.  That is like what we expect will be the
> general case of this: a debugger thread wants to sleep somehow and have
> its report_* callbacks say "wake the debugger so it can examine me".
>
> So, how does the utrace module writer build that?  You'd probably use
> wait_event() et al in your debugger thread, and wake_up() in report_*
> callbacks.

OK.

> (That's approximately what you have in ptrace+wait.)

Hmm. Except in this case ptracer can be running. It is not placed
on any wqh, but still needs a notification.

> So how much is satisfied with a "delayed wake-up" (rather than an
> open-ended hook).  Let's say:
>
> 	utrace_wake_up(task, engine, wqh);	// replaces wake_up(wqh);
> 	return UTRACE_STOP; // | UTRACE_SIGNAL_IGN|UTRACE_SIGNAL_HOLD
>
> That would mean, approximately, as if wake_up(wqh) and then the wakee
> had called utrace_barrier(task,engine), but without the sched flutter.
>
> Formally, I think the guarantee should be "when utrace_barrier would
> return for you".  Technically this means that if your callback did not
> use UTRACE_STOP, it's just sometime after your callback returns.  But if
> you did use UTRACE_STOP, then it means after the task will definitely
> stop.

This looks nice, but

> That's all it means today, but I think we want to strengthen that
> guarantee so that when you have used UTRACE_STOP (either in a callback
> already in progress when you called utrace_barrier, or in a utrace_control
> call before the utrace_barrier call), utrace_barrier doesn't return until
> "utrace_prepare_examine will work", i.e. actually in TASK_TRACED/STOPPED.

this means the meaning of utrace_barrier() should be changed?

> In ptrace, I think this alone might suffice to cover things "cleanly" in
> the utrace API.  (That is, clean for utrace. ;-) The ptrace layer could
> use the trick of a custom wake function to implement SIGCHLD

A custom wake function can only be used if the wakee has already called
add_wait_queue(). Wake function belongs to wait_queue_t, not to
wait_queue_head_t.

But this doesn't really matter. I think that using wait_queue_func_t->func()
(or whatever else we use to implement the utrace-delayed-wakeup) to do
ptrace-specific hacks is not better than engine->ops->special_hook().

In essence, this looks like we add another ->ops into engine implicitly.

> without
> needing anything but utrace_wake_up from the utrace layer.

Not sure I understand how to implement this all :(

Oleg.