From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 38A747E for ; Wed, 2 Aug 2023 00:40:59 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 08023C433C7; Wed, 2 Aug 2023 00:40:57 +0000 (UTC) Date: Tue, 1 Aug 2023 20:40:54 -0400 From: Steven Rostedt To: "Masami Hiramatsu (Google)" Cc: Alexei Starovoitov , linux-trace-kernel@vger.kernel.org, LKML , Martin KaFai Lau , bpf , Sven Schnelle , Alexei Starovoitov , Jiri Olsa , Arnaldo Carvalho de Melo , Daniel Borkmann , Alan Maguire , Mark Rutland , Florent Revest , Peter Zijlstra , Thomas Gleixner Subject: Re: [PATCH v4 3/9] bpf/btf: Add a function to search a member of a struct/union Message-ID: <20230801204054.3884688e@rorschach.local.home> In-Reply-To: <20230802092146.9bda5e49528e6988ab97899c@kernel.org> References: <169078860386.173706.3091034523220945605.stgit@devnote2> <169078863449.173706.2322042687021909241.stgit@devnote2> <20230801085724.9bb07d2c82e5b6c6a6606848@kernel.org> <20230802000228.158f1bd605e497351611739e@kernel.org> <20230801112036.0d4ee60d@gandalf.local.home> <20230801113240.4e625020@gandalf.local.home> <20230801190920.7a1abfd5@gandalf.local.home> <20230802092146.9bda5e49528e6988ab97899c@kernel.org> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Precedence: bulk X-Mailing-List: bpf@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Wed, 2 Aug 2023 09:21:46 +0900 Masami Hiramatsu (Google) wrote: > > Then use kprobes. When I asked Masami what the difference between fprobes > > and kprobes was, he told me that it would be that it would no longer rely > > on the slower FTRACE_WITH_REGS. But currently, it still does. > > kprobes needs to keep using pt_regs because software-breakpoint exception > handler gets that. And fprobe is used for bpf multi-kprobe interface, > but I think it can be optional. > > So until user-land tool supports the ftrace_regs, you can just disable > using fprobes if CONFIG_DYNAMIC_FTRACE_WITH_REGS=n I'm confused. I asked about the difference between kprobes on ftrace and fprobes, and you said it was to get rid of the requirement of FTRACE_WITH_REGS. https://lore.kernel.org/all/20230120205535.98998636329ca4d5f8325bc3@kernel.org/ > > Then you can safely use > > struct pt_regs *regs = ftrace_get_regs(fregs); > > I think we can just replace the CONFIG_FPROBE ifdefs with > CONFIG_DYNAMIC_FTRACE_WITH_REGS in kernel/trace/bpf_trace.c > And that will be the first version of using ftrace_regs in fprobe. But it is still slow. The FTRACE_WITH_REGS gives us the full pt_regs and saves all registers including flags, which is a very slow operation (and noticeable in profilers). And this still doesn't work on arm64. Maybe we can add a ftrace_partial_regs(fregs) that returns a partially filled pt_regs, and the caller that uses this obviously knows its partial (as it's in the name). But this doesn't quite help out arm64 because unlike x86, struct ftrace_regs does not contain an address compatibility with pt_regs fields. It would need to do a copy. ftrace_partial_regs(fregs, ®s) ? -- Steve