On 10/15, Roland McGrath wrote:
We have a callback
void my_report_callback(...)
{
if (ptr)
dereference(ptr);
}
And the tracer does:
void *tmp = ptr;
ptr = NULL;
utrace_barrier(my_engine);
kfree(tmp);
This
I still didn't find the time to read the code around set/clear -reporting,
it is subtle and needs a fresh head.
Ok. I had remembered that your earlier reviews included review all use of
memory barriers in utrace, so I didn't realize this stuff needed review.
But at least, I think
On 09/09, Roland McGrath wrote:
2. Is utrace_barrier() correct Note the example above,
it assumes that utrace_barrier() itself is the barrier
wrt reporting. But, is it?
I don't think I understand the question.
Sorry for delay on this. I have a lot of emails
1. Can't we set -reporting _after_ checking engine-flags ?
(unlikely)
I'm not sure...it is early the morning again. ;-)
2. Is utrace_barrier() correct Note the example above,
it assumes that utrace_barrier() itself is the barrier
wrt reporting.
But more importantly, I think utrace_reap() never needs to synchronize
with utrace_barrier(). Once we drop utrace-lock, any other caller which
takes this lock must see both -exit_state and utrace-reap. This means
utrace_control() or utrace_set_events() which sets/clears REAP must not
succeed.
utrace_reap(), like other reporting loops, sets/clears utrace-reporting,
but this is not needed.
We already set -ops = NULL, this means utrace_barrier() will never look
at reporting. get_utrace_lock() can not succeed, it must return -ESRCH
and utrace_barrier() just returns in this case.
But more
