public inbox for systemtap@sourceware.org
 help / color / mirror / Atom feed
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)

  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).