that no disabled callback might be made. You'd get
-EINPROGRESS any time we aren't 100% positive of that guarantee.
> Actually, I think it would also be useful to just have a
> utrace_clear_events_sync() that encapsulates the above call. I can see
> use for it outside of an asynchrono
_events(task, engine, 0), right?
Actually, I think it would also be useful to just have a
utrace_clear_events_sync() that encapsulates the above call. I can see
use for it outside of an asynchronous detach, for cases when one needs
to just turn tracing events off on a thread. (It is definitely not
> I don't think the module-unloading case is so special.
It is, because there is nothing else you can do about that case yourself.
For managing your own data structures, your callbacks can use e.g.:
rcu_read_lock();
ptr = rcu_dereference(engine->data);
if (!ptr) punt;
> Thinking aloud, utrace_control(UTRACE_STOP) returns -EINPROGRESS for
> threads not yet stopped
> a. possibly still in userspace, yet to pass through a quiesce safe point
> b. blocked in the kernel on a syscall or an exception.
Correct.
> Would task_current_syscall() help here? On a -EINPROGRESS
Roland McGrath <[EMAIL PROTECTED]> writes:
> [...]
> What the utrace interface has always said about this is, "So don't do
> that." [...]
> What I overlooked is that not just your data structures, but your
> callbacks too might be going away, i.e. unloading the kernel module.
I don't think the m
A subject that came up recently for David Smith is asynchronous detach.
So I've been thinking about accomodating it better in the interface.
One of the TODO features that I've been wanting to get to soon is global
tracing. It so happens that David's work could use this feature.
