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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 44A42C43334 for ; Sat, 23 Jul 2022 21:39:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230306AbiGWVje (ORCPT ); Sat, 23 Jul 2022 17:39:34 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42952 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229473AbiGWVje (ORCPT ); Sat, 23 Jul 2022 17:39:34 -0400 Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AF9B61928A for ; Sat, 23 Jul 2022 14:39:32 -0700 (PDT) Received: by mail-wm1-x336.google.com with SMTP id a18-20020a05600c349200b003a30de68697so6329943wmq.0 for ; Sat, 23 Jul 2022 14:39:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:date:from:from:to:cc; bh=Can+tmBk+Wid7peUFFK03StsCKEQpkEmFqhp/kE6KsE=; b=ipERumaARiNZsuwJDDqcplfldFnM1+XYa2m2j/5kEzsPGd45px3pbVkDnTxMOT8YXK csiB7UKjMnEgh2J+DYWtgHkppIcDA36d20NHSp+ca14VuJ19C/aNk1M4sjr25Aa3brq1 XRzJBaEVBgMX7utwy7lb2QFvTLEI4p4uWHdLZm9Gsva0xXO4WqFw7CyluKYMScUG3mt+ L1676/sofUOpgLO6o8WRaa13Rl5trMYFdG82lOyFjCf7YXq4aJzz2hnZs7485DquT+Gc fz2K6w5PoXeyl802lGaM/tRKQ41I1Bo1p3gih1qWETrObPCkdzeiYX3Oj+SaQKo05lLq 6RRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:date:from:x-gm-message-state:from:to:cc; bh=Can+tmBk+Wid7peUFFK03StsCKEQpkEmFqhp/kE6KsE=; b=UEGY5gNm+nKJD3MyufpCYuXRu2F9DkV5uMUkkjouF6rHN/qOvDbWjeVMTXHYgVwlhT voFpOjXTq7WeszdcZyDtVdAnrsnylnHp2KVfkFMqRQCDehVFC3e5kgr7Hyhe5STwxA1q 7v6Gl4W+rfgwzkRYFZG30zGXo2F1IrZLKhE9jmh7z3MXbt5g2CZ3PVeBWzO5jp8HwrvX VE2rlQiQLwtje8ognybw2aycQIJtcKFUSnMYolWKEghN3ybipHJ2eFQJNlM3aCgtysCf 5LJne8pkQeYNg/BysC9qZczE+9nhRIpmkK0DrCtM22iIvYW6VhBHAi5haCavXaQzp96I BKXg== X-Gm-Message-State: AJIora/c1m9IntBXYTMem2J0gSJAs32851f6FCmqai/7mr5yxeLifRlo cpWUoeXHavZhFuHH8om05qzpCfqz8hSoGw== X-Google-Smtp-Source: AGRyM1sGNCkwfLkVoaVdvf7ieAvhrIx/iXvYs6sXTHRTMWAHfXb0tsgFpgbMImMQYlMlCDstNmqX/Q== X-Received: by 2002:a05:600c:1c26:b0:3a3:2251:c3cb with SMTP id j38-20020a05600c1c2600b003a32251c3cbmr16534754wms.126.1658612371159; Sat, 23 Jul 2022 14:39:31 -0700 (PDT) Received: from krava (ip-94-113-247-30.net.vodafone.cz. [94.113.247.30]) by smtp.gmail.com with ESMTPSA id m39-20020a05600c3b2700b003a2e1883a27sm16680062wms.18.2022.07.23.14.39.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 23 Jul 2022 14:39:30 -0700 (PDT) From: Jiri Olsa X-Google-Original-From: Jiri Olsa Date: Sat, 23 Jul 2022 23:39:27 +0200 To: Steven Rostedt Cc: Jiri Olsa , Alexei Starovoitov , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Ingo Molnar , bpf , Martin KaFai Lau , Song Liu , Yonghong Song , John Fastabend , KP Singh , Stanislav Fomichev , Hao Luo Subject: Re: [RFC] ftrace: Add support to keep some functions out of ftrace Message-ID: References: <20220722110811.124515-1-jolsa@kernel.org> <20220722072608.17ef543f@rorschach.local.home> <20220722120854.3cc6ec4b@gandalf.local.home> <20220722122548.2db543ca@gandalf.local.home> <20220722174120.688768a3@gandalf.local.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220722174120.688768a3@gandalf.local.home> Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org On Fri, Jul 22, 2022 at 05:41:20PM -0400, Steven Rostedt wrote: > On Fri, 22 Jul 2022 23:05:19 +0200 > Jiri Olsa wrote: > > > ok, I think we could use that, I'll check > > > > > > > > But other than that, we don't need infrastructure to hide any mcount/fentry > > > locations from ftrace. Those were add *for* ftrace. > > > > I think I understand the fentry/ftrace equivalence you see, I remember > > the perl mcount script ;-) > > It's even more than that. We worked with the compiler folks to get fentry > for ftrace purposes (namely to speed it up, and not rely on frame > pointers, which mcount did). fentry never existed until then. Like I said. > fentry was created *for* ftrace. And currently it's x86 specific, as it > relies on the calling convention that a call does both, push the return > address onto the stack, and jump to a function. The blr > (branch-link-register) method is more complex, which is where the > "patchable" work comes from. > > > > > still I think we should be able to define function that has fentry > > profile call and be able to manage it without ftrace > > > > one other thought.. how about adding function that would allow to disable > > function in ftrace, with existing FTRACE_FL_DISABLED or some new flag > > > > that way ftrace still keeps track of it, but won't allow to use it in > > ftrace infra > > Another way is to remove it at compile time from the mcount_loc table, and > add it to your own table. I take it, this is for bpf infrastructure code hm, perhaps we could move it to separate object and switch off -mrecord-mcount for it, I'll check > and not for any code that's in the day to day processing of the kernel, > right? yes, it's bpf specific code thanks, jirka