From: David Smith <dsmith@redhat.com>
To: Torsten Polle <Torsten.Polle@gmx.de>, systemtap@sourceware.org
Subject: Re: [PATCH] stap/staprun do not terminate properly
Date: Fri, 07 Mar 2014 21:09:00 -0000 [thread overview]
Message-ID: <531A3581.7050009@redhat.com> (raw)
In-Reply-To: <m2k3c7uiaa.fsf@gmx.de>
On 03/06/2014 03:30 PM, Torsten Polle wrote:
> Hi,
>
> I'm using the uprobes-inode with task_finder2.c and had two problems,
> when I wanted to terminate my probe runs.
>
> I tested the patches with uprobes-inode and the utrace based version.
>
> Kind Regards,
> Torsten
Torsten,
Thanks *so* much for the patches. I've seen a hang in stap around this
area, but I could never reproduce it.
I checked the 1st patch in as commit e695d46 and the 2nd patch (tweaked)
in as commit 9ee1bfe.
I tweaked the 2nd patch just a bit. Originally the flow went like:
====
stap_stap_task_finder()
{
// ...
// Note that utrace_exit() calls stp_task_work_exit()
utrace_exit();
__stp_tf_cancel_task_work();
}
====
Your patch changed it to this:
====
stap_stap_task_finder()
{
// ...
utrace_exit();
// Note that __stp_tf_cancel_task_work() calls
// stp_task_work_exit()
__stp_tf_cancel_task_work();
}
====
I saw what you were doing, but that didn't "feel" quite right.
utrace_init() calls stp_task_work_init(), so it made sense for
utrace_exit() to call stp_task_work_exit().
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.
BTW, if you have a good idea for a reproducer for the original problem
I'd like to see it. Perhaps I could add a test case for it.
Thanks again for the patches!
--
David Smith
dsmith@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)
next prev parent reply other threads:[~2014-03-07 21:09 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-06 21:30 Torsten Polle
2014-03-07 21:09 ` David Smith [this message]
2014-03-07 22:11 ` Torsten Polle
2014-03-10 22:36 ` Josh Stone
2014-03-12 14:11 ` David Smith
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=531A3581.7050009@redhat.com \
--to=dsmith@redhat.com \
--cc=Torsten.Polle@gmx.de \
--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).