From: Masami Hiramatsu <mhiramat@kernel.org>
To: Daniel Borkmann <daniel@iogearbox.net>
Cc: Josef Bacik <josef@toxicpanda.com>,
rostedt@goodmis.org, mingo@redhat.com, davem@davemloft.net,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
ast@kernel.org, kernel-team@fb.com, linux-btrfs@vger.kernel.org,
darrick.wong@oracle.com, Josef Bacik <jbacik@fb.com>
Subject: Re: [PATCH v10 3/5] bpf: add a bpf_override_function helper
Date: Tue, 19 Dec 2017 15:38:08 +0900 [thread overview]
Message-ID: <20171219153808.83bb43e8a9b206e0e034fc6b@kernel.org> (raw)
In-Reply-To: <73e451e0-64ce-6f77-5f8b-bde39a181941@iogearbox.net>
On Mon, 18 Dec 2017 16:09:30 +0100
Daniel Borkmann <daniel@iogearbox.net> wrote:
> On 12/18/2017 10:51 AM, Masami Hiramatsu wrote:
> > On Fri, 15 Dec 2017 14:12:54 -0500
> > Josef Bacik <josef@toxicpanda.com> wrote:
> >> From: Josef Bacik <jbacik@fb.com>
> >>
> >> Error injection is sloppy and very ad-hoc. BPF could fill this niche
> >> perfectly with it's kprobe functionality. We could make sure errors are
> >> only triggered in specific call chains that we care about with very
> >> specific situations. Accomplish this with the bpf_override_funciton
> >> helper. This will modify the probe'd callers return value to the
> >> specified value and set the PC to an override function that simply
> >> returns, bypassing the originally probed function. This gives us a nice
> >> clean way to implement systematic error injection for all of our code
> >> paths.
> >
> > OK, got it. I think the error_injectable function list should be defined
> > in kernel/trace/bpf_trace.c because only bpf calls it and needs to care
> > the "safeness".
> >
> > [...]
> >> diff --git a/arch/x86/kernel/kprobes/ftrace.c b/arch/x86/kernel/kprobes/ftrace.c
> >> index 8dc0161cec8f..1ea748d682fd 100644
> >> --- a/arch/x86/kernel/kprobes/ftrace.c
> >> +++ b/arch/x86/kernel/kprobes/ftrace.c
> >> @@ -97,3 +97,17 @@ int arch_prepare_kprobe_ftrace(struct kprobe *p)
> >> p->ainsn.boostable = false;
> >> return 0;
> >> }
> >> +
> >> +asmlinkage void override_func(void);
> >> +asm(
> >> + ".type override_func, @function\n"
> >> + "override_func:\n"
> >> + " ret\n"
> >> + ".size override_func, .-override_func\n"
> >> +);
> >> +
> >> +void arch_ftrace_kprobe_override_function(struct pt_regs *regs)
> >> +{
> >> + regs->ip = (unsigned long)&override_func;
> >> +}
> >> +NOKPROBE_SYMBOL(arch_ftrace_kprobe_override_function);
> >
> > Calling this as "override_function" is meaningless. This is a function
> > which just return. So I think combination of just_return_func() and
> > arch_bpf_override_func_just_return() will be better.
> >
> > Moreover, this arch/x86/kernel/kprobes/ftrace.c is an archtecture
> > dependent implementation of kprobes, not bpf.
>
> Josef, please work out any necessary cleanups that would still need
> to be addressed based on Masami's feedback and send them as follow-up
> patches, thanks.
>
> > Hmm, arch/x86/net/bpf_jit_comp.c will be better place?
>
> (No, it's JIT only and I'd really prefer to keep it that way, mixing
> this would result in a huge mess.)
OK, that is same to kprobes. kernel/kprobes.c and arch/x86/kernel/kprobe/*
are for instrumentation code. And kernel/trace/trace_kprobe.c is ftrace's
kprobe user interface, just one implementation of kprobe usage. So please
do not mix it up. It will result in a huge mess to me.
Thank you,
--
Masami Hiramatsu <mhiramat@kernel.org>
next prev parent reply other threads:[~2017-12-19 6:38 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-15 19:12 [PATCH v10 0/5] Add the ability to do BPF directed error injection Josef Bacik
2017-12-15 19:12 ` [PATCH v10 1/5] add infrastructure for tagging functions as error injectable Josef Bacik
2017-12-18 9:11 ` Masami Hiramatsu
2017-12-19 6:29 ` Masami Hiramatsu
2017-12-20 2:14 ` Alexei Starovoitov
2017-12-20 7:13 ` Masami Hiramatsu
2017-12-20 10:09 ` Daniel Borkmann
2017-12-20 17:22 ` Alexei Starovoitov
2017-12-20 11:00 ` Masami Hiramatsu
2017-12-20 17:33 ` Alexei Starovoitov
2017-12-15 19:12 ` [PATCH v10 2/5] btrfs: make open_ctree " Josef Bacik
2017-12-15 19:12 ` [PATCH v10 3/5] bpf: add a bpf_override_function helper Josef Bacik
2017-12-15 20:34 ` Alexei Starovoitov
2017-12-15 20:53 ` Daniel Borkmann
2017-12-18 9:51 ` Masami Hiramatsu
2017-12-18 15:09 ` Daniel Borkmann
2017-12-19 6:38 ` Masami Hiramatsu [this message]
2017-12-15 19:12 ` [PATCH v10 4/5] samples/bpf: add a test for bpf_override_return Josef Bacik
2017-12-15 19:12 ` [PATCH v10 5/5] btrfs: allow us to inject errors at io_ctl_init Josef Bacik
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=20171219153808.83bb43e8a9b206e0e034fc6b@kernel.org \
--to=mhiramat@kernel.org \
--cc=ast@kernel.org \
--cc=daniel@iogearbox.net \
--cc=darrick.wong@oracle.com \
--cc=davem@davemloft.net \
--cc=jbacik@fb.com \
--cc=josef@toxicpanda.com \
--cc=kernel-team@fb.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=rostedt@goodmis.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).