Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Fri, 18 Nov 2022 16:18:32 +0000
From:   Mark Rutland <mark.rutland@arm.com>
To:     Chris Mason <clm@meta.com>
Cc:     Steven Rostedt <rostedt@goodmis.org>,
        Alexei Starovoitov <alexei.starovoitov@gmail.com>,
        Florent Revest <revest@chromium.org>,
        bpf <bpf@vger.kernel.org>, Alexei Starovoitov <ast@kernel.org>,
        Daniel Borkmann <daniel@iogearbox.net>,
        Andrii Nakryiko <andrii@kernel.org>,
        KP Singh <kpsingh@kernel.org>,
        Brendan Jackman <jackmanb@google.com>, markowsky@google.com,
        Masami Hiramatsu <mhiramat@kernel.org>,
        Xu Kuohai <xukuohai@huawei.com>,
        LKML <linux-kernel@vger.kernel.org>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Christoph Hellwig <hch@infradead.org>,
        Peter Zijlstra <peterz@infradead.org>
Subject: Re: [RFC 0/1] BPF tracing for arm64 using fprobe
Message-ID: <Y3ewWJITWH2b4ihI@FVFF77S0Q05N.cambridge.arm.com>
References: <20221108220651.24492-1-revest@chromium.org>
 <CAADnVQ+BWpzqOV8dGCR=A3dR3u60CkBkqSXEQHe2kVqFzsgnHw@mail.gmail.com>
 <20221117121617.4e1529d3@gandalf.local.home>
 <d24cded7-87b1-89f5-fc2a-5346669f6d57@meta.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <d24cded7-87b1-89f5-fc2a-5346669f6d57@meta.com>
Precedence: bulk

On Thu, Nov 17, 2022 at 04:55:12PM -0500, Chris Mason wrote:
> On 11/17/22 12:16 PM, Steven Rostedt wrote:
> > On Wed, 16 Nov 2022 18:41:26 -0800
> > Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
> > 
> > > Even with all optimization the performance overhead is not acceptable.
> > > It feels to me that folks are still thinking about bpf trampoline
> > > as a tracing facility.
> > > It's a lot more than that. It needs to run 24/7 with zero overhead.
> > 
> > It obviously doesn't have zero overhead.
> > 
> > And correctness and maintainability trumps micro-optimizations.
> 
> During the bpf office hours today Mark Rutland and Florent had some
> great ideas about how to wire things up.  I'm sure Mark will need some
> time to write it all down but it was a fun call.

I'd hoped to write that up today, but I haven't had enough time yet, so I'll
try to write up that proposal next week.

The rough idea was to *somehow* rejig the per-callsite ftrace_ops code I've
been working on to permit (but not require) the use of custom trampolines. As
mentioned during the call I want to ensure that this doesn't adversely affect
regular ftrace usage, and I'd also like to ensure that the regular ftrace code
is able to gain form those changes (without the need for trampolines). AFAICT,
that's likely to require some rework to the way direct functions are managed.

The WIP code for per-callsite ftrace_ops is at:

 https://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git/log/?h=arm64/ftrace/per-callsite-ops

To be clear, my comments were purely about the *mechanism* we end up
implementing. I do have concerns w.r.t. overriding arbitrary parts of the
kernel.

Thanks,
Mark.