From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30077 invoked by alias); 7 Mar 2014 21:09:29 -0000 Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org Received: (qmail 30066 invoked by uid 89); 7 Mar 2014 21:09:28 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.9 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 07 Mar 2014 21:09:26 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s27L9MFu009114 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 7 Mar 2014 16:09:23 -0500 Received: from t510.usersys.redhat.com (vpn-63-113.rdu2.redhat.com [10.10.63.113]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s27L9LI5013718 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 7 Mar 2014 16:09:22 -0500 Message-ID: <531A3581.7050009@redhat.com> Date: Fri, 07 Mar 2014 21:09:00 -0000 From: David Smith User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Torsten Polle , systemtap@sourceware.org Subject: Re: [PATCH] stap/staprun do not terminate properly References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2014-q1/txt/msg00265.txt.bz2 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)