From: Peter Zijlstra <peterz@infradead.org>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: "Steven Rostedt" <rostedt@goodmis.org>,
"Björn Töpel" <bjorn.topel@gmail.com>,
"Network Development" <netdev@vger.kernel.org>,
"Alexei Starovoitov" <ast@kernel.org>,
"Daniel Borkmann" <daniel@iogearbox.net>,
"Björn Töpel" <bjorn.topel@intel.com>, bpf <bpf@vger.kernel.org>,
"Magnus Karlsson" <magnus.karlsson@gmail.com>,
"Karlsson, Magnus" <magnus.karlsson@intel.com>,
"Jonathan Lemon" <jonathan.lemon@gmail.com>,
"Edward Cree" <ecree@solarflare.com>,
"Toke Høiland-Jørgensen" <thoiland@redhat.com>,
"Jesper Dangaard Brouer" <brouer@redhat.com>,
"Andrii Nakryiko" <andrii.nakryiko@gmail.com>,
LKML <linux-kernel@vger.kernel.org>,
"Linus Torvalds" <torvalds@linux-foundation.org>,
"Christoph Hellwig" <hch@infradead.org>,
"Josh Poimboeuf" <jpoimboe@redhat.com>,
"Thomas Gleixner" <tglx@linutronix.de>,
"Andrew Morton" <akpm@linux-foundation.org>
Subject: Re: [PATCH bpf-next v4 2/6] bpf: introduce BPF dispatcher
Date: Mon, 15 Aug 2022 16:56:43 +0200 [thread overview]
Message-ID: <Yvpeq+vPz63n8gmi@worktop.programming.kicks-ass.net> (raw)
In-Reply-To: <CAADnVQLhHm-gxJXTbWxJN0fFGW_dyVV+5D-JahVA1Wrj2cGu7g@mail.gmail.com>
On Mon, Aug 15, 2022 at 07:31:23AM -0700, Alexei Starovoitov wrote:
> On Mon, Aug 15, 2022 at 7:13 AM Steven Rostedt <rostedt@goodmis.org> wrote:
> >
> > On Wed, 11 Dec 2019 13:30:13 +0100
> > Björn Töpel <bjorn.topel@gmail.com> wrote:
> >
> > > From: Björn Töpel <bjorn.topel@intel.com>
> > >
> > > The BPF dispatcher is a multi-way branch code generator, mainly
> > > targeted for XDP programs. When an XDP program is executed via the
> > > bpf_prog_run_xdp(), it is invoked via an indirect call. The indirect
> > > call has a substantial performance impact, when retpolines are
> > > enabled. The dispatcher transform indirect calls to direct calls, and
> > > therefore avoids the retpoline. The dispatcher is generated using the
> > > BPF JIT, and relies on text poking provided by bpf_arch_text_poke().
> > >
> > > The dispatcher hijacks a trampoline function it via the __fentry__ nop
> >
> > Why was the ftrace maintainers not Cc'd on this patch? I would have NACKED
> > it. Hell, it wasn't even sent to LKML! This was BPF being sneaky in
> > updating major infrastructure of the Linux kernel without letting the
> > stakeholders of this change know about it.
> >
> > For some reason, the BPF folks think they own the entire kernel!
> >
> > When I heard that ftrace was broken by BPF I thought it was something
> > unique they were doing, but unfortunately, I didn't investigate what they
> > were doing at the time.
>
> ftrace is still broken and refusing to accept the fact doesn't make it
> non-broken.
Alexei, stop this. The 'call __fentry__' sites are owned by ftrace.
Always have been. If BPF somehow thinks it can use them without telling
ftrace then it's BPF that's broken.
> > Then they started sending me patches to hide fentry locations from ftrace.
> > And even telling me that fentry != ftrace
>
> It sounds that you've invented nop5 and kernel's ability
> to replace nop5 with a jump or call.
Ftrace has introduced the mcount/fentry patching into the kernel and has
always owned it for those sites. There is a lot of other text writing
not owned by ftrace. But the fentry sites are ftrace's.
Ftrace was also the one that got us the text_poke_bp() infrastructure
and got it reviewed by the CPU vendors.
Since then we've grown static_branch and static_call, they have their
own patch sites and do no interfere with ftrace.
> ftrace should really stop trying to own all of the kernel text rewrites.
> It's in the way. Like this case.
It doesn't. It hasn't. But it *does* own the fentry sites.
> It was implemented long before static_calls made it to the kernel
> and it's different.
It wasn't long before. Yes it landed a few months prior to the
static_call work, but the whole static_call thing was in progress for a
long long time.
Anyway, yes it is different. But it's still very much broken. You simply
cannot step on __fentry__ sites like that.
next prev parent reply other threads:[~2022-08-15 14:57 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-11 12:30 [PATCH bpf-next v4 0/6] Introduce the BPF dispatcher Björn Töpel
2019-12-11 12:30 ` [PATCH bpf-next v4 1/6] bpf: move trampoline JIT image allocation to a function Björn Töpel
2019-12-11 12:30 ` [PATCH bpf-next v4 2/6] bpf: introduce BPF dispatcher Björn Töpel
2019-12-11 13:26 ` Toke Høiland-Jørgensen
2019-12-13 8:23 ` Björn Töpel
2019-12-13 5:30 ` Alexei Starovoitov
2019-12-13 7:51 ` Björn Töpel
2019-12-13 15:04 ` Alexei Starovoitov
2019-12-13 15:49 ` Björn Töpel
2019-12-13 15:51 ` Alexei Starovoitov
2019-12-13 15:59 ` Björn Töpel
2019-12-13 16:03 ` Alexei Starovoitov
2019-12-13 16:09 ` Björn Töpel
2019-12-13 17:18 ` Alexei Starovoitov
2022-08-15 14:13 ` Steven Rostedt
2022-08-15 14:31 ` Alexei Starovoitov
2022-08-15 14:56 ` Peter Zijlstra [this message]
2022-08-15 15:16 ` Steven Rostedt
2022-08-15 15:19 ` Alexei Starovoitov
2022-08-15 15:21 ` Steven Rostedt
2022-08-15 15:39 ` Steven Rostedt
2019-12-11 12:30 ` [PATCH bpf-next v4 3/6] bpf, xdp: start using the BPF dispatcher for XDP Björn Töpel
2019-12-11 12:30 ` [PATCH bpf-next v4 4/6] bpf: start using the BPF dispatcher in BPF_TEST_RUN Björn Töpel
2019-12-11 12:30 ` [PATCH bpf-next v4 5/6] selftests: bpf: add xdp_perf test Björn Töpel
2019-12-11 12:30 ` [PATCH bpf-next v4 6/6] bpf, x86: align dispatcher branch targets to 16B Björn Töpel
2019-12-11 12:33 ` [PATCH bpf-next v4 0/6] Introduce the BPF dispatcher Björn Töpel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Yvpeq+vPz63n8gmi@worktop.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=akpm@linux-foundation.org \
--cc=alexei.starovoitov@gmail.com \
--cc=andrii.nakryiko@gmail.com \
--cc=ast@kernel.org \
--cc=bjorn.topel@gmail.com \
--cc=bjorn.topel@intel.com \
--cc=bpf@vger.kernel.org \
--cc=brouer@redhat.com \
--cc=daniel@iogearbox.net \
--cc=ecree@solarflare.com \
--cc=hch@infradead.org \
--cc=jonathan.lemon@gmail.com \
--cc=jpoimboe@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=magnus.karlsson@gmail.com \
--cc=magnus.karlsson@intel.com \
--cc=netdev@vger.kernel.org \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
--cc=thoiland@redhat.com \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).