From: Steven Rostedt <rostedt@goodmis.org>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: Alexei Starovoitov <ast@kernel.org>,
davem@davemloft.net, daniel@iogearbox.net, peterz@infradead.org,
x86@kernel.org, netdev@vger.kernel.org, bpf@vger.kernel.org,
kernel-team@fb.com, Thomas Gleixner <tglx@linutronix.de>,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCH bpf-next 0/7] Introduce BPF trampoline
Date: Tue, 5 Nov 2019 10:40:24 -0500 [thread overview]
Message-ID: <20191105104024.4e99a630@grimm.local.home> (raw)
In-Reply-To: <20191105143154.umojkotnvcx4yeuq@ast-mbp.dhcp.thefacebook.com>
On Tue, 5 Nov 2019 06:31:56 -0800
Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
> Steven,
> look slike your branch hasn't been updated in 13 days.
> Are you still planning to fix the bugs and send it in for the merge window?
> I cannot afford to wait a full release, since I have my own follow for
> XDP/networking based on this and other folks are building their stuff on top of
> BPF trampoline too. So I'm thinking for v2 I will switch to using text_poke()
> and add appropriate guard checks, so it will be safe out of the box without
> ftrace dependency. If register_ftrace_direct() indeed comes in soon I'll
> switch to that and will make bpf trampoline to co-operate with ftrace.
> text_poke approach will make it such that what ever comes first to trace the
> fentry (either bpf trampoline or ftrace) will grab the nop and the other system
> will not be able to attach. That's safe and correct, but certainly not nice
> long term. So the fix will be needed. The key point that switching to text_poke
> will remove the register_ftrace_direct() dependency, unblock bpf developers and
> will give you time to land your stuff at your pace.
Alexei,
I am still working on it, and if it seems stable enough I will submit
it for this merge window, but there's no guarantees. It's ready when
it's ready. I gave 5 talks last week (4 in Lyon, and one is Sofia,
Bulgaria), thus I did not have time to work on it then. I'm currently
in the Sofia office, and I got a version working that seems to be
stable. But I still have to break it up into a patch series, and run it
through more stress tests.
If you have to wait you may need to wait. The Linux kernel isn't
something that is suppose to put in temporary hacks, just to satisfy
someone's deadline. Feel free to fork the kernel if you need to. That's
what everyone else does.
The RT patch has been out of tree specifically because we never pushed
in the hacks to make it work. We could have landed RT in the tree years
ago, but we *never* pushed in something that wasn't ready. I suggest
the BPF folks follow suit.
-- Steve
next prev parent reply other threads:[~2019-11-05 15:40 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-02 22:00 [PATCH bpf-next 0/7] Introduce BPF trampoline Alexei Starovoitov
2019-11-02 22:00 ` [PATCH bpf-next 1/7] bpf, ftrace: temporary workaround Alexei Starovoitov
2019-11-02 22:00 ` [PATCH bpf-next 2/7] bpf: refactor x86 JIT into helpers Alexei Starovoitov
2019-11-02 22:00 ` [PATCH bpf-next 3/7] bpf: Introduce BPF trampoline Alexei Starovoitov
2019-11-05 19:51 ` Andrii Nakryiko
2019-11-02 22:00 ` [PATCH bpf-next 4/7] libbpf: Add support to attach to fentry/fexit tracing progs Alexei Starovoitov
2019-11-05 21:17 ` Andrii Nakryiko
2019-11-05 23:17 ` Alexei Starovoitov
2019-11-02 22:00 ` [PATCH bpf-next 5/7] selftest/bpf: Simple test for fentry/fexit Alexei Starovoitov
2019-11-05 21:37 ` Andrii Nakryiko
2019-11-02 22:00 ` [PATCH bpf-next 6/7] bpf: Add kernel test functions for fentry testing Alexei Starovoitov
2019-11-02 22:00 ` [PATCH bpf-next 7/7] selftests/bpf: Add test for BPF trampoline Alexei Starovoitov
2019-11-05 21:50 ` Andrii Nakryiko
2019-11-05 14:31 ` [PATCH bpf-next 0/7] Introduce " Alexei Starovoitov
2019-11-05 15:40 ` Steven Rostedt [this message]
2019-11-05 15:47 ` Alexei Starovoitov
2019-11-05 16:00 ` Steven Rostedt
2019-11-05 16:28 ` Alexei Starovoitov
2019-11-05 17:26 ` Steven Rostedt
2019-11-05 17:59 ` Alexei Starovoitov
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=20191105104024.4e99a630@grimm.local.home \
--to=rostedt@goodmis.org \
--cc=alexei.starovoitov@gmail.com \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=kernel-team@fb.com \
--cc=netdev@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=x86@kernel.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).