[PATCH] stap/staprun do not terminate properly
Josh Stone
jistone@redhat.com
Mon Mar 10 22:36:00 GMT 2014
On 03/07/2014 01:09 PM, David Smith wrote:
> So, instead I did this:
>
> ====
> stap_stap_task_finder()
> {
> // ...
>
> __stp_tf_cancel_task_work();
>
> // Note that utrace_exit() calls stp_task_work_exit()
> utrace_exit();
> }
> ====
>
> This moves canceling all outstanding task_work items before shutting
> down utrace (and calling stp_task_work_exit()). I think the end result
> is the same as your patch, and I think this makes a little more sense.
> This way we've canceled all the task_work items before shutting down
> utrace (and freeing all the memory allocated for utrace).
>
> If this doesn't work for you or you see a hole in this logic please let
> me know.
I notice that utrace_exit() calls utrace_shutdown(), but so does
__stp_task_finder_cleanup() earlier in stap_stop_task_finder(). So in
fact the shutdown is still happening before canceling this work, and the
only thing left for utrace_exit() is the kmem_cache_destroy and
stp_task_work_exit(). Do you think this could be a problem?
In particular, I worry about this comment:
/* After calling tracepoint_synchronize_unregister(), we're
* sure there are no outstanding tracepoint probes being
* called. So, now would be a great time to free everything. */
There won't be any outstanding tracepoint handlers, but couldn't there
still be outstanding task_work scheduled from those handlers?
More information about the Systemtap
mailing list