From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29449 invoked by alias); 4 Aug 2016 13:57:04 -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 29370 invoked by uid 89); 4 Aug 2016 13:57:03 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.1 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy= 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; Thu, 04 Aug 2016 13:56:47 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 6749D4A54A; Thu, 4 Aug 2016 13:56:46 +0000 (UTC) Received: from [10.13.129.231] (dhcp129-231.rdu.redhat.com [10.13.129.231]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u74DujvQ009725; Thu, 4 Aug 2016 09:56:45 -0400 Subject: Re: exercising current aarch64 kprobe support with systemtap To: Pratyush Anand References: <576C29E1.8060805@linaro.org> <0a594132-796b-779d-b473-a06c0f3e8ae8@redhat.com> <20160627141840.GB8139@dhcppc9> <577EA7EE.2070607@linaro.org> <20160803131302.GC18785@localhost.localdomain> <2947a749-a518-d560-f768-60cc2f2c691e@redhat.com> <20160804044230.GB22191@localhost.localdomain> Cc: David Long , systemtap@sourceware.org, Mark Brown , Jeremy Linton , David Smith , "Frank Ch. Eigler" From: William Cohen Message-ID: Date: Thu, 04 Aug 2016 13:57:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160804044230.GB22191@localhost.localdomain> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-q3/txt/msg00128.txt.bz2 On 08/04/2016 12:42 AM, Pratyush Anand wrote: > Hi Will, > > On 03/08/2016:01:39:47 PM, William Cohen wrote: >> On 08/03/2016 09:13 AM, Pratyush Anand wrote: >>> On 07/07/2016:03:58:37 PM, Frank Ch. Eigler wrote: >>>> David Long writes: >>>> >>>>> [...] >>>>>> - bug_handler() calls report_bug() which calls __warn() >>>>>> - __warn() does lot of pr_warn() which invokes print_worker_info() >>>>>> where we have a kprobe instrumented. >>>>>> - Therefore, we are encountering this issue. >>> >>> Hi Will, >>> >>> Can you please cross-check if following branch works perfectly with >>> kprobes_onthefly.exp and other systemtap tests. >>> >>> https://github.com/pratyushanand/linux/tree/uprobe/upstream_arm64_devel_v1.1 >>> >>> Following patch in above branch should solve this issue. >>> https://github.com/pratyushanand/linux/commit/d0dcc6477f1279ab0bd99aefc30efdecb16c586e >>> >>> However, I am not yet sure that above modification could be the best solution, >>> so discussing at arm kernel list. >>> >>> ~Pratyush >>> >> >> I have an AMD seattle machine set up Fedora24, the upstream_arm64_devel_v1.1 branch kernel locally built, and a locally built checkout of systemtap (systemtap rpm in fc24 doesn't generate models for linux 4.6 and newer kernels). Tried to run the systemtap tests with: >> >> make installcheck RUNTESTFLAGS="--debug systemtap.onthefly/kprobes_onthefly.exp" >> >> However at some point the kernel starts having problems: >> >> http://paste.stg.fedoraproject.org/5375/ > > Yes, this is what you were getting with earlier code as well, but now it is not > going to infinite unexpected EL1, so at least proposed kprobe improvement seems > fine to me. > > In this failing test we are getting oom and the oom_killer is called. So, > I think, this is another point of investigation that why this OOM occurs. > > ~Pratyush > Hi, The OOM errors came before the otf_stress_hard_iter_5000 test that previous triggered the infinite unexpected EL1, so can't really say that the proposed patch has fixed the problem. Any thoughts on how to track down the oom issue? Are you able to replicate it running the systemtap onthefly/kprobes_onthefly.exp tests? -Will