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=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_2 autolearn=no 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 C0765C433B4 for ; Thu, 15 Apr 2021 18:18:37 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id A1207611BF for ; Thu, 15 Apr 2021 18:18:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234379AbhDOSS7 (ORCPT ); Thu, 15 Apr 2021 14:18:59 -0400 Received: from mail.kernel.org ([198.145.29.99]:39212 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233052AbhDOSS6 (ORCPT ); Thu, 15 Apr 2021 14:18:58 -0400 Received: from gandalf.local.home (cpe-66-24-58-225.stny.res.rr.com [66.24.58.225]) (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 8BB0B610EA; Thu, 15 Apr 2021 18:18:32 +0000 (UTC) Date: Thu, 15 Apr 2021 14:18:31 -0400 From: Steven Rostedt To: Jiri Olsa Cc: Andrii Nakryiko , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Networking , bpf , Martin KaFai Lau , Song Liu , Yonghong Song , John Fastabend , KP Singh , Daniel Xu , Jesper Brouer , Toke =?UTF-8?B?SMO4aWxhbmQtSsO4cmdlbnNlbg==?= , Viktor Malik Subject: Re: [PATCHv2 RFC bpf-next 0/7] bpf: Add support for ftrace probe Message-ID: <20210415141831.7b8fbe72@gandalf.local.home> In-Reply-To: References: <20210413121516.1467989-1-jolsa@kernel.org> <20210415111002.324b6bfa@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: netdev@vger.kernel.org On Thu, 15 Apr 2021 19:39:45 +0200 Jiri Olsa wrote: > > I don't know how the BPF code does it, but if you are tracing the exit > > of a function, I'm assuming that you hijack the return pointer and replace > > it with a call to a trampoline that has access to the arguments. To do > > hi, > it's bit different, the trampoline makes use of the fact that the > call to trampoline is at the very begining of the function and, so > it can call the origin function with 'call function + 5' instr. > > so in nutshell the trampoline does: > > call entry_progs > call original_func+5 How does the above handle functions that have parameters on the stack? > call exit_progs > > you can check this in arch/x86/net/bpf_jit_comp.c in moe detail: > > * The assembly code when eth_type_trans is called from trampoline: > * > * push rbp > * mov rbp, rsp > * sub rsp, 24 // space for skb, dev, return value > * push rbx // temp regs to pass start time > * mov qword ptr [rbp - 24], rdi // save skb pointer to stack > * mov qword ptr [rbp - 16], rsi // save dev pointer to stack > * call __bpf_prog_enter // rcu_read_lock and preempt_disable > * mov rbx, rax // remember start time if bpf stats are enabled > * lea rdi, [rbp - 24] // R1==ctx of bpf prog > * call addr_of_jited_FENTRY_prog // bpf prog can access skb and dev > > entry program called ^^^ > > * movabsq rdi, 64bit_addr_of_struct_bpf_prog // unused if bpf stats are off > * mov rsi, rbx // prog start time > * call __bpf_prog_exit // rcu_read_unlock, preempt_enable and stats math > * mov rdi, qword ptr [rbp - 24] // restore skb pointer from stack > * mov rsi, qword ptr [rbp - 16] // restore dev pointer from stack > * call eth_type_trans+5 // execute body of eth_type_trans > > original function called ^^^ This would need to be limited to only functions that do not have any parameters on the stack. > > * mov qword ptr [rbp - 8], rax // save return value > * call __bpf_prog_enter // rcu_read_lock and preempt_disable > * mov rbx, rax // remember start time in bpf stats are enabled > * lea rdi, [rbp - 24] // R1==ctx of bpf prog > * call addr_of_jited_FEXIT_prog // bpf prog can access skb, dev, return value > > exit program called ^^^ > > * movabsq rdi, 64bit_addr_of_struct_bpf_prog // unused if bpf stats are off > * mov rsi, rbx // prog start time > * call __bpf_prog_exit // rcu_read_unlock, preempt_enable and stats math > * mov rax, qword ptr [rbp - 8] // restore eth_type_trans's return value > * pop rbx > * leave > * add rsp, 8 // skip eth_type_trans's frame > * ret // return to its caller > > > this you need a shadow stack to save the real return as well as the > > parameters of the function. This is something that I have patches that do > > similar things with function graph. > > > > If you want this feature, lets work together and make this work for both > > BPF and ftrace. > > it's been some time I saw a graph tracer, is there a way to make it > access input arguments and make it available through ftrace_ops > interface? I have patches that could easily make it do so. And should probably get them out again. The function graph tracer has a shadow stack, and my patches allow you to store data on it for use with the exiting of the program. My last release of that code is here: https://lore.kernel.org/lkml/20190525031633.811342628@goodmis.org/ It allows you to "reserve data" to pass from the caller to the return, and that could hold the arguments. See patch 15 of that series. -- Steve