[Bug runtime/26144] New: task finder: vma maps callback may run after other task finder callbacks

[agentzh at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=26144

            Bug ID: 26144
           Summary: task finder: vma maps callback may run after other
                    task finder callbacks
           Product: systemtap
           Version: unspecified
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: runtime
          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).

Below is the logs demonstrating this bad case:

https://gist.github.com/agentzh/c2e99a87c6aae652bb2eb6d39c20c077

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.