From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 17B49C32789 for ; Fri, 2 Nov 2018 16:13:13 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id BE54A2082E for ; Fri, 2 Nov 2018 16:13:12 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BE54A2082E Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=goodmis.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728027AbeKCBUs (ORCPT ); Fri, 2 Nov 2018 21:20:48 -0400 Received: from mail.kernel.org ([198.145.29.99]:34564 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726085AbeKCBUs (ORCPT ); Fri, 2 Nov 2018 21:20:48 -0400 Received: from gandalf.local.home (cpe-66-24-56-78.stny.res.rr.com [66.24.56.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id AF6E12081B; Fri, 2 Nov 2018 16:13:08 +0000 (UTC) Date: Fri, 2 Nov 2018 12:13:07 -0400 From: Steven Rostedt To: Josh Poimboeuf Cc: Aleksa Sarai , "Naveen N. Rao" , Anil S Keshavamurthy , "David S. Miller" , Masami Hiramatsu , Jonathan Corbet , Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , Alexander Shishkin , Jiri Olsa , Namhyung Kim , Shuah Khan , Alexei Starovoitov , Daniel Borkmann , Brendan Gregg , Christian Brauner , Aleksa Sarai , netdev@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org Subject: Re: [PATCH v3 1/2] kretprobe: produce sane stack traces Message-ID: <20181102121307.32e99414@gandalf.local.home> In-Reply-To: <20181102154325.bt6xoysl4xdl33wd@treble> References: <20181101083551.3805-1-cyphar@cyphar.com> <20181101083551.3805-2-cyphar@cyphar.com> <20181101204720.6ed3fe37@vmware.local.home> <20181102050509.tw3dhvj5urudvtjl@yavin> <20181102065932.bdt4pubbrkvql4mp@yavin> <20181102091658.1bc979a4@gandalf.local.home> <20181102154325.bt6xoysl4xdl33wd@treble> X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 2 Nov 2018 10:43:26 -0500 Josh Poimboeuf wrote: > > I'll hopefully have a prototype ready by plumbers. > > Why do we need multiple users? It would be a lot simpler if we could > just enforce a single user per fgraphed/kretprobed function (and return > -EBUSY if it's already being traced/probed). Because that means if function graph tracer is active, then you can't do a kretprobe, and vice versa. I'd really like to have it working for multiple users, then we could trace different graph functions and store them in different buffers. It would also allow for perf to use function graph tracer too. > > > And this too will require each architecture to probably change. As a > > side project to this, I'm going to try to consolidate the function > > graph code among all the architectures as well. Not an easy task. > > Do you mean implementing HAVE_FUNCTION_GRAPH_RET_ADDR_PTR for all the > arches? If so, I think have an old crusty patch which attempted to > that. I could try to dig it up if you're interested. > I'd like to have that, but it still requires some work. But I'd just the truly architecture dependent code be in the architecture (basically the asm code), and have the ability to move most of the duplicate code out of the archs. -- Steve From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steven Rostedt Subject: Re: [PATCH v3 1/2] kretprobe: produce sane stack traces Date: Fri, 2 Nov 2018 12:13:07 -0400 Message-ID: <20181102121307.32e99414@gandalf.local.home> References: <20181101083551.3805-1-cyphar@cyphar.com> <20181101083551.3805-2-cyphar@cyphar.com> <20181101204720.6ed3fe37@vmware.local.home> <20181102050509.tw3dhvj5urudvtjl@yavin> <20181102065932.bdt4pubbrkvql4mp@yavin> <20181102091658.1bc979a4@gandalf.local.home> <20181102154325.bt6xoysl4xdl33wd@treble> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Aleksa Sarai , "Naveen N. Rao" , Anil S Keshavamurthy , "David S. Miller" , Masami Hiramatsu , Jonathan Corbet , Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , Alexander Shishkin , Jiri Olsa , Namhyung Kim , Shuah Khan , Alexei Starovoitov , Daniel Borkmann , Brendan Gregg , Christian Brauner , Aleksa Sarai , netdev@vger.kernel.org, linux-doc@vger.ker To: Josh Poimboeuf Return-path: In-Reply-To: <20181102154325.bt6xoysl4xdl33wd@treble> Sender: linux-kernel-owner@vger.kernel.org List-Id: netdev.vger.kernel.org On Fri, 2 Nov 2018 10:43:26 -0500 Josh Poimboeuf wrote: > > I'll hopefully have a prototype ready by plumbers. > > Why do we need multiple users? It would be a lot simpler if we could > just enforce a single user per fgraphed/kretprobed function (and return > -EBUSY if it's already being traced/probed). Because that means if function graph tracer is active, then you can't do a kretprobe, and vice versa. I'd really like to have it working for multiple users, then we could trace different graph functions and store them in different buffers. It would also allow for perf to use function graph tracer too. > > > And this too will require each architecture to probably change. As a > > side project to this, I'm going to try to consolidate the function > > graph code among all the architectures as well. Not an easy task. > > Do you mean implementing HAVE_FUNCTION_GRAPH_RET_ADDR_PTR for all the > arches? If so, I think have an old crusty patch which attempted to > that. I could try to dig it up if you're interested. > I'd like to have that, but it still requires some work. But I'd just the truly architecture dependent code be in the architecture (basically the asm code), and have the ability to move most of the duplicate code out of the archs. -- Steve From mboxrd@z Thu Jan 1 00:00:00 1970 From: rostedt at goodmis.org (Steven Rostedt) Date: Fri, 2 Nov 2018 12:13:07 -0400 Subject: [PATCH v3 1/2] kretprobe: produce sane stack traces In-Reply-To: <20181102154325.bt6xoysl4xdl33wd@treble> References: <20181101083551.3805-1-cyphar@cyphar.com> <20181101083551.3805-2-cyphar@cyphar.com> <20181101204720.6ed3fe37@vmware.local.home> <20181102050509.tw3dhvj5urudvtjl@yavin> <20181102065932.bdt4pubbrkvql4mp@yavin> <20181102091658.1bc979a4@gandalf.local.home> <20181102154325.bt6xoysl4xdl33wd@treble> Message-ID: <20181102121307.32e99414@gandalf.local.home> On Fri, 2 Nov 2018 10:43:26 -0500 Josh Poimboeuf wrote: > > I'll hopefully have a prototype ready by plumbers. > > Why do we need multiple users? It would be a lot simpler if we could > just enforce a single user per fgraphed/kretprobed function (and return > -EBUSY if it's already being traced/probed). Because that means if function graph tracer is active, then you can't do a kretprobe, and vice versa. I'd really like to have it working for multiple users, then we could trace different graph functions and store them in different buffers. It would also allow for perf to use function graph tracer too. > > > And this too will require each architecture to probably change. As a > > side project to this, I'm going to try to consolidate the function > > graph code among all the architectures as well. Not an easy task. > > Do you mean implementing HAVE_FUNCTION_GRAPH_RET_ADDR_PTR for all the > arches? If so, I think have an old crusty patch which attempted to > that. I could try to dig it up if you're interested. > I'd like to have that, but it still requires some work. But I'd just the truly architecture dependent code be in the architecture (basically the asm code), and have the ability to move most of the duplicate code out of the archs. -- Steve From mboxrd@z Thu Jan 1 00:00:00 1970 From: rostedt@goodmis.org (Steven Rostedt) Date: Fri, 2 Nov 2018 12:13:07 -0400 Subject: [PATCH v3 1/2] kretprobe: produce sane stack traces In-Reply-To: <20181102154325.bt6xoysl4xdl33wd@treble> References: <20181101083551.3805-1-cyphar@cyphar.com> <20181101083551.3805-2-cyphar@cyphar.com> <20181101204720.6ed3fe37@vmware.local.home> <20181102050509.tw3dhvj5urudvtjl@yavin> <20181102065932.bdt4pubbrkvql4mp@yavin> <20181102091658.1bc979a4@gandalf.local.home> <20181102154325.bt6xoysl4xdl33wd@treble> Message-ID: <20181102121307.32e99414@gandalf.local.home> Content-Type: text/plain; charset="UTF-8" Message-ID: <20181102161307._3Y9IAiHv2xp9JAfGOdacQKVgIe2TcPVIrdL7y3gD3A@z> On Fri, 2 Nov 2018 10:43:26 -0500 Josh Poimboeuf wrote: > > I'll hopefully have a prototype ready by plumbers. > > Why do we need multiple users? It would be a lot simpler if we could > just enforce a single user per fgraphed/kretprobed function (and return > -EBUSY if it's already being traced/probed). Because that means if function graph tracer is active, then you can't do a kretprobe, and vice versa. I'd really like to have it working for multiple users, then we could trace different graph functions and store them in different buffers. It would also allow for perf to use function graph tracer too. > > > And this too will require each architecture to probably change. As a > > side project to this, I'm going to try to consolidate the function > > graph code among all the architectures as well. Not an easy task. > > Do you mean implementing HAVE_FUNCTION_GRAPH_RET_ADDR_PTR for all the > arches? If so, I think have an old crusty patch which attempted to > that. I could try to dig it up if you're interested. > I'd like to have that, but it still requires some work. But I'd just the truly architecture dependent code be in the architecture (basically the asm code), and have the ability to move most of the duplicate code out of the archs. -- Steve