From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7753 invoked by alias); 28 Oct 2015 02:30:13 -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 7697 invoked by uid 89); 28 Oct 2015 02:30:06 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.0 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD autolearn=no version=3.3.2 X-HELO: mail1.windriver.com Received: from mail1.windriver.com (HELO mail1.windriver.com) (147.11.146.13) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Wed, 28 Oct 2015 02:30:05 +0000 Received: from ALA-HCA.corp.ad.wrs.com (ala-hca.corp.ad.wrs.com [147.11.189.40]) by mail1.windriver.com (8.15.2/8.15.1) with ESMTPS id t9S2U10E012490 (version=TLSv1 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 27 Oct 2015 19:30:01 -0700 (PDT) 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; Tue, 27 Oct 2015 19:30:00 -0700 Subject: Re: [PATCH 1/1] stp: rt: replace spin_lock with stp style lock and use STP_ALLOC_FLAGS To: David Smith , References: <1445499965-23777-1-git-send-email-yanjun.zhu@windriver.com> <56290FFC.3030407@redhat.com> <562D9BAA.7040704@windriver.com> <562E9AE0.6030501@redhat.com> From: yzhu1 Message-ID: <56303328.5030603@windriver.com> Date: Wed, 28 Oct 2015 02:30: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: <562E9AE0.6030501@redhat.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-q4/txt/msg00075.txt.bz2 On 10/27/2015 05:28 AM, David Smith wrote: > On 10/25/2015 10:19 PM, yzhu1 wrote: >> Hi, David >> >> I do not have this backtrace. Because STP_ALLOC_SLEEP_FLAGS will cause >> kmalloc sleep, >> so I replaced it with STP_ALLOC_FLAGS. > Evidently I'm not explaining myself well, I'll try again in more detail. > > We've got 2 sets of allocation flags in systemtap: > > STP_ALLOC_FLAGS: These are the default flags and allocations using this > set of flags will not sleep. > > STP_ALLOC_SLEEP_FLAGS: These flags are only supposed to be used from > contexts where it is safe to sleep (like begin probes). > > Here's the big question - on the realtime kernel, is it ever safe to sleep? > > If the answer to the previous question is "no", then your change is correct. > > If the answer to the previous question is "yes", then your change isn't > correct. Instead, we need to look at uses of STP_ALLOC_SLEEP_FLAGS, > because we're using the wrong set of flags somewhere. We're using > STP_ALLOC_SLEEP_FLAGS in an allocation that should be using STP_ALLOC_FLAGS. > > I see 6 uses of STP_ALLOC_SLEEP_FLAGS in the systemtap source. If we > can't get a backtrace, then I'll need you to change the 6 uses of > STP_ALLOC_SLEEP_FLAGS to STP_ALLOC_FLAGS one at a time to figure out > which use of STP_ALLOC_SLEEP_FLAGS isn't correct. > > Thanks for continuing to work this problem. Hi, All OK. I will do. Zhu Yanjun > > >> Zhu Yanjun >> >> On 10/23/2015 12:34 AM, David Smith wrote: >>> On 10/22/2015 02:46 AM, Zhu Yanjun wrote: >>>> -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. >>> In general, this patch looks fine. However, I'm not too sure about the >>> STP_ALLOC_SLEEP_FLAGS bit. Can show us a backtrace that happens with >>> your spinlock changes but without the alloc flags changes or explain why >>> the alloc flags change is necessary? It could be that we're using the >>> wrong set of flags in the caller. >>> >>> Thanks. >>> >