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 948FAC7EE25 for ; Fri, 9 Jun 2023 17:13:04 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229755AbjFIRND (ORCPT ); Fri, 9 Jun 2023 13:13:03 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60748 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229773AbjFIRNC (ORCPT ); Fri, 9 Jun 2023 13:13:02 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8EE6C3C00; Fri, 9 Jun 2023 10:12:57 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id BAC9265A37; Fri, 9 Jun 2023 17:12:56 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 184B2C433EF; Fri, 9 Jun 2023 17:12:54 +0000 (UTC) Date: Fri, 9 Jun 2023 13:12:53 -0400 From: Steven Rostedt To: Jiri Olsa Cc: Mark Rutland , Andrii Nakryiko , Masami Hiramatsu , Andrii Nakryiko , lkml , linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, Jackie Liu Subject: Re: [PATCH RFC] ftrace: Show all functions with addresses in available_filter_functions_addrs Message-ID: <20230609131253.0d67e746@gandalf.local.home> In-Reply-To: References: <20230608212613.424070-1-jolsa@kernel.org> <20230608192748.435a1dbf@gandalf.local.home> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-trace-kernel@vger.kernel.org On Fri, 9 Jun 2023 09:44:36 -0700 Jiri Olsa wrote: > On Fri, Jun 09, 2023 at 09:24:10AM +0100, Mark Rutland wrote: > > > > Do you need the address of the function entry-point or the address of the > > patch-site within the function? Those can differ, and the rec->ip address won't > > necessarily equal the address in /proc/kallsyms, so the pointer in > > /proc/kallsyms won't (always) match the address we could print for the ftrace site. > > > > On arm64, today we can have offsets of +0, +4, and +8, and within a single > > kernel image different functions can have different offsets. I suspect in > > future that we may have more potential offsets (e.g. due to changes for HW/SW > > CFI). > > so we need that for kprobe_multi bpf link, which is based on fprobe, > and that uses ftrace_set_filter_ips to setup the ftrace_ops filter > > and ftrace_set_filter_ips works fine with ip address being the address > of the patched instruction (it's matched in ftrace_location) Yes, exactly. And it's off with the old "mcount" way of doing things too. > > but right, I did not realize this.. it might cause confusion if people > don't know it's patch-side addresses.. not sure if there's easy way to > get real function address out of rec->ip, but it will also get more > complicated on x86 when IBT is enabled, will check > > or we could just use patch-side addresses and reflect that in the file's > name like 'available_filter_functions_patch_addrs' .. it's already long > name ;-) No! "available_filter_function_addrs" is enough to know that it's not kallsyms. It's the filtered function address, which is enough description. If people don't RTFM, then too bad ;-) You can use ftrace_location() that takes an instruction pointer, and will return the rec->ip of that function as long as it lands in between the function's kallsyms start and end values. -- Steve