Re: UTRACE_STOP race condition?

[Frank Ch. Eigler]

Renzo Davoli re...@cs.unibo.it writes:

 [...]
 If the report function returns UTRACE_STOP the traced process stays in a
 quiescent state and the module wakes it up by a 
 utrace_control(...,UTRACE_RESUME) call *later*.
 [...]
 If the module wakes the traced process too quickly, utrace has not yet put
 it into a stopped state, therefore UTRACE_RESUME gets lost.
 [...]
 The module has decided UTRACE_STOP at t=1, then the module can call
 utrace_control(...,UTRACE_RESUME) at any t1. [...]

This may not answer your question, but I believe it is not proper to
to make this call at any time t1, only once you receive the quiesce
callback.


- FChE

Re: UTRACE_STOP race condition?

[Renzo Davoli]

On Wed, Feb 11, 2009 at 09:45:15AM -0500, Frank Ch. Eigler wrote:
 This may not answer your question, but I believe it is not proper to
 to make this call at any time t1, only once you receive the quiesce
 callback.

Maybe I am wrong but the quiesce callback gets called *before* the other
report_* (say syscall_entry).

So when I capture UTRACE_QUIESCE, I got the report call before t=1.

Some communication from utrace to the module should happen *after* 
utrace-stopped is set to 1 
(something similar to the code Roland added for ptrace).



Even if it worked this way (i.e. return STOP and wait for report_quiesce,
I think the race condition there is in any case) the interface
to the module would be horrible.

When the module receives a report callback, it returns UTRACE_STOP and
then it needs to use some data structure to wait for a report_quiesce
to restart the traced process.

With the idea of patch included in my previous mail there is no need of
such a complexity.

Thank you for taking part to this discussion

renzo