On 06/22, Roland McGrath wrote:
OTOH, I am wondering if we can give more power to utrace_control(STOP).
Currently debugger can't stop the tracee unless it cooperates. However, if
the tracee doesn't have UTRACE_EVENT(QUIESCE), then utrace_control(STOP)
works. This is strange.
Why is it
OK. But then perhaps UTRACE_STICKY_STOP makes sense even without the
races we discussed. It can simplify the cooperation in this case.
The only cooperation methods we should consider are those that cover all
their races.
Yes. Let's consider the concrete example. The tracee is going to
stop
On 06/21, Roland McGrath wrote:
I am wondering if there is another way to handle such a race...
Suppose we
- add UTRACE_STOP_XXX
- modify utrace_control(UTRACE_STOP_XXX) to do
mark_engine_wants_stop() and nothing more.
utrace_control(current,,UTRACE_STOP) doesn't
utrace_control(current,,UTRACE_STOP) doesn't really do anything more.
It does utrace_do_stop() which sets UTRACE_REPORT/TIF_NOTIFY_RESUME.
Harmless, but makes sense to avoid.
Right. I was talking about the API perspective. Those internal details
are more or less invisible to a given
On 06/17, Alpár Török wrote:
The producer is a utrace monitored task. At any time there is an
arbitrary number of producers. On sys_entry and sys_exit the producers
do :
slot = book_message_in_buffer(buf);
if (slot 0) {
/* no slot can be alocated, producer must sleep */
I think Roland is right. Let's forget about utrace for the moment,
this code looks like
if (!CONDITION) {
set_task_state(TASK_XXX);
schedule();
}
and it can obviously race with
CONDITION = true;
wake_up_xxx();
This is Linux
2010/6/13 Roland McGrath rol...@redhat.com:
Thanks for your interest in utrace.
It's correct that passing UTRACE_REPORT to utrace_control should
always ensure you get some report_* callback before the tracee returns
to user mode.
However, I think your use may be susceptible to a race
You should use linux/wait.h or similar facilities rather than calling
schedule() and wake_up_process() directly. This doesn't have anything to
do with utrace, it's just the clean practice for normal kinds of blocking
in the kernel, for a variety of reasons. That has to do with how your
control
Thanks for your interest in utrace.
It's correct that passing UTRACE_REPORT to utrace_control should
always ensure you get some report_* callback before the tracee returns
to user mode.
However, I think your use may be susceptible to a race between
resumption by utrace_control, and the
Hi,
I have the following scenario:
Producer consumer model. The traced tasks are producers, and there is
one consumer. Produces produce data in a buffer. If the buffer is
full,
the producer registers itself into a list (lock protected) and returns
UTRACE_STOP. The consumer always checks the
10 matches
Mail list logo
