From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5287 invoked by alias); 26 Oct 2015 21:28:07 -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 5272 invoked by uid 89); 26 Oct 2015 21:28:06 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.4 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS 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 (AES256-GCM-SHA384 encrypted) ESMTPS; Mon, 26 Oct 2015 21:28:05 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id 5C78F8535A; Mon, 26 Oct 2015 21:28:04 +0000 (UTC) Received: from t540p.usersys.redhat.com (vpn-53-60.rdu2.redhat.com [10.10.53.60]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t9QLS1pW010910 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Oct 2015 17:28:03 -0400 Subject: Re: [PATCH 1/1] stp: rt: replace spin_lock with stp style lock and use STP_ALLOC_FLAGS To: yzhu1 , systemtap@sourceware.org References: <1445499965-23777-1-git-send-email-yanjun.zhu@windriver.com> <56290FFC.3030407@redhat.com> <562D9BAA.7040704@windriver.com> From: David Smith Message-ID: <562E9AE0.6030501@redhat.com> Date: Mon, 26 Oct 2015 21:28:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <562D9BAA.7040704@windriver.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-q4/txt/msg00063.txt.bz2 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. > > 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. >> > -- David Smith dsmith@redhat.com Red Hat http://www.redhat.com 256.217.0141 (direct) 256.837.0057 (fax)