From: "agentzh at gmail dot com" <sourceware-bugzilla@sourceware.org>
To: systemtap@sourceware.org
Subject: [Bug runtime/26144] New: task finder: vma maps callback may run after other task finder callbacks
Date: Sun, 21 Jun 2020 06:51:49 +0000 [thread overview]
Message-ID: <bug-26144-6586@http.sourceware.org/bugzilla/> (raw)
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.
reply other threads:[~2020-06-21 6:51 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bug-26144-6586@http.sourceware.org/bugzilla/ \
--to=sourceware-bugzilla@sourceware.org \
--cc=systemtap@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).