Bug ID: 26144
Summary: task finder: vma maps callback may run after other
task finder callbacks
Assignee: systemtap at sourceware dot org
Reporter: agentzh at gmail dot com
Target Milestone: ---
I've noted on fedora's kernel-debug package's kernels, it's easy to reproduce
the case where __stp_utrace_task_finder_target_quiesce() fails to run the
callbacks because the current context does not allow sleeping. Then the
callbacks would be postponed using stp_task_work_add() which in turn calls
task_work_add(). The task_work_add() always adds the callbacks in the reversed
order, which leads to the incorrect result of running vma maps callback after
other callbacks (like process.begin's).
It seems the correct fix would be combining all the callbacks, including the
vma maps and other task finder callbacks, into a single utrace attach callback.
If we always handle all callbacks for each target task as a single entity, it
would be possible to ensure the execution order of these callbacks, even in the
case of non-sleeping contexts and task_work_add(). Any better ideas would be
highly appreciated. Thanks!
You are receiving this mail because:
You are the assignee for the bug.