I was going to ping you ;) This is connected to the problem I hit today.
Despite the fact I already complained about utrace_get_signal() && QUIESCE,
I forgot about this and figured out it doesn't work in practice.
On 09/02, Roland McGrath wrote:
>
> > > If an engine used UTRACE_INTERRUPT without having first set QUIESCE,
> > > then it has no rightful expectation of getting any callback.
> >
> > Hmm. This is certainly new to me. Could you confirm?
>
> Well, I didn't say it precisely correctly. UTRACE_INTERRUPT serves two
> purposes. First, it just interrupts things like a signal would. You could
> use that on its own without even tracing any events at all, just do achieve
> fault injection or similar. Second, it's like UTRACE_REPORT.
Yes, this is clear.
> As with UTRACE_REPORT, after UTRACE_INTERRUPT you can expect to get some
> report_quiesce callback even if there is no other event you were tracing
> that happens. For this to actually happen, you need to have
> UTRACE_EVENT(QUIESCE) set.
Hmm. I am not sure I understand. If ->report_signal != NULL, then
you can't expect ->report_quiesce() after utrace_control(INTERRUPT) ?
> So, it is technically kosher enough to use UTRACE_INTERRUPT without
> UTRACE_EVENT(QUIESCE) set, if you really know the situation and are sure
> about all those caveats above.
How? see below.
> But, it's only UTRACE_EVENT(QUIESCE) that
> gives you any expectation of an "extra" callback for "no event" from either
> UTRACE_REPORT or UTRACE_INTERRUPT.
Yes, this is clear too.
So. Now I am even more confused. First of all, ugdb (at least currently)
does not need report_quiesce() and UTRACE_EVENT(QUIESCE) at all. OK, this
is not 100% true due to multitracing/etc, lets ignore this. Anyway it
makes sense to clear QUIESCE after $c to avoid the unnecessary callbacks.
All it needs is ->report_signal(). But, the problem is, it is not called
after utrace_control(INTERRUPT) ! You need QUIESCE to ensure report_signal()
will be called, and this looks at least strange to me.
Once again, I am not asking to change utrace now, but could you explain
what is wrong with the patch below?
Oleg.
--- x/kernel/utrace.c
+++ x/kernel/utrace.c
@@ -2029,7 +2029,8 @@ int utrace_get_signal(struct task_struct
report.spurious = false;
finish_resume_report(task, utrace, &report);
return -1;
- } else if (!(task->utrace_flags & UTRACE_EVENT(QUIESCE))) {
+ } else if (!(task->utrace_flags &
+ (UTRACE_EVENT(QUIESCE) |
UTRACE_EVENT_SIGNAL_ALL))) {
/*
* We only got here to clear utrace->signal_handler.
*/
