From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1176 invoked by alias); 18 Nov 2015 08:14:59 -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 1095 invoked by uid 89); 18 Nov 2015 08:14:58 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.5 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD autolearn=no version=3.3.2 X-HELO: mail5.wrs.com Received: from mail5.windriver.com (HELO mail5.wrs.com) (192.103.53.11) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 18 Nov 2015 08:14:55 +0000 Received: from ALA-HCA.corp.ad.wrs.com (ala-hca.corp.ad.wrs.com [147.11.189.40]) by mail5.wrs.com (8.15.2/8.15.2) with ESMTPS id tAI8EnB5010729 (version=TLSv1 cipher=AES128-SHA bits=128 verify=OK); Wed, 18 Nov 2015 00:14:50 -0800 Received: from [128.224.162.133] (128.224.162.133) by ALA-HCA.corp.ad.wrs.com (147.11.189.50) with Microsoft SMTP Server (TLS) id 14.3.248.2; Wed, 18 Nov 2015 00:14:49 -0800 Subject: Re: [PATCH 1/1] stp: rt: replace spin_lock with stp style lock and use STP_ALLOC_FLAGS To: David Smith , , References: <1447747786-29733-1-git-send-email-yanjun.zhu@windriver.com> <1447747786-29733-2-git-send-email-yanjun.zhu@windriver.com> <564B599D.3000506@redhat.com> From: yzhu1 Message-ID: <564C337B.7060306@windriver.com> Date: Wed, 18 Nov 2015 08:14:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <564B599D.3000506@redhat.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-q4/txt/msg00145.txt.bz2 Hi, David Thanks for your comments. I can not reproduce this problem. And my user can reproduce this problem ocassionly. And I requested him to help me to make tests about your changes. But he refused. So I made auto tests in systemtap after this patch is applied. And I can not find any regressions about this patch. Best Regards! Zhu Yanjun On 11/18/2015 12:45 AM, David Smith wrote: > On 11/17/2015 02:09 AM, yzhu1 wrote: >> From: Zhu Yanjun >> >> -rt mode spin lock lead to __might_sleep calltrace. >> Replacing spin lock with stp type raw lock and >> changing STP_ALLOC_SLEEP_FLAGS to STP_ALLOC_FLAGS solves the problem. > I have the same comment I had before. The raw lock changes are fine, but > I still don't believe the STP_ALLOC_SLEEP_FLAGS change is correct, at > least not without some further explanation. In the call trace below, > STP_ALLOC_SLEEP_FLAGS wasn't used from what I can tell. > > Did you get a chance to try running systemtap with your raw lock changes > and the added might_sleep() call patch I sent you? > >> Call Trace: >> [] dump_stack+0x19/0x1b >> [] __might_sleep+0xef/0x160 >> [] rt_spin_lock+0x20/0x50 >> [] d_path+0x79/0x1a0 >> [] __stp_get_mm_path.constprop.79+0x49/0x90 [stap_f5bb3e3c9b162aab5a51afc2375fe9cf_2073] >> [] __stp_utrace_attach_match_tsk.isra.53+0x7b/0x1b0 [stap_f5bb3e3c9b162aab5a51afc2375fe9cf_2073] >> [] __stp_utrace_task_finder_report_exec+0x3c/0x50 [stap_f5bb3e3c9b162aab5a51afc2375fe9cf_2073] >> [] utrace_report_exec+0xb9/0x100 [stap_f5bb3e3c9b162aab5a51afc2375fe9cf_2073] >> [] search_binary_handler+0x332/0x380 >> [] do_execve_common.isra.24+0x55c/0x640 >> [] do_execve+0x18/0x20 >> [] SyS_execve+0x32/0x50 >> [] stub_execve+0x69/0xa0 >