From: Josef Bacik <josef@toxicpanda.com>
To: 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, daniel@iogearbox.net,
linux-btrfs@vger.kernel.org
Subject: [PATCH v8 0/5] Add the ability to do BPF directed error injection
Date: Wed, 6 Dec 2017 11:12:12 -0500 [thread overview]
Message-ID: <1512576737-9417-1-git-send-email-josef@toxicpanda.com> (raw)
Jon noticed that I had a typo in my _ASM_KPROBE_ERROR_INJECT macro. I went to
figure out why the compiler didn't catch it and it's because it was not used
anywhere. I had copied it from the trace blacklist code without understanding
where it was used as cscope didn't find the original macro I was looking for, so
I assumed it was some voodoo and left it in place. Turns out cscope failed me
and I didn't need the macro at all, the trace blacklist thing I was looking at
was for marking assembly functions as blacklisted and I have no intention of
marking assembly functions as error injectable at the moment.
v7->v8:
- removed the _ASM_KPROBE_ERROR_INJECT since it was not needed.
v6->v7:
- moved the opt-in macro to bpf.h out of kprobes.h.
v5->v6:
- add BPF_ALLOW_ERROR_INJECTION() tagging for functions that will support this
feature. This way only functions that opt-in will be allowed to be
overridden.
- added a btrfs patch to allow error injection for open_ctree() so that the bpf
sample actually works.
v4->v5:
- disallow kprobe_override programs from being put in the prog map array so we
don't tail call into something we didn't check. This allows us to make the
normal path still fast without a bunch of percpu operations.
v3->v4:
- fix a build error found by kbuild test bot (I didn't wait long enough
apparently.)
- Added a warning message as per Daniels suggestion.
v2->v3:
- added a ->kprobe_override flag to bpf_prog.
- added some sanity checks to disallow attaching bpf progs that have
->kprobe_override set that aren't for ftrace kprobes.
- added the trace_kprobe_ftrace helper to check if the trace_event_call is a
ftrace kprobe.
- renamed bpf_kprobe_state to bpf_kprobe_override, fixed it so we only read this
value in the kprobe path, and thus only write to it if we're overriding or
clearing the override.
v1->v2:
- moved things around to make sure that bpf_override_return could really only be
used for an ftrace kprobe.
- killed the special return values from trace_call_bpf.
- renamed pc_modified to bpf_kprobe_state so bpf_override_return could tell if
it was being called from an ftrace kprobe context.
- reworked the logic in kprobe_perf_func to take advantage of bpf_kprobe_state.
- updated the test as per Alexei's review.
- Original message -
A lot of our error paths are not well tested because we have no good way of
injecting errors generically. Some subystems (block, memory) have ways to
inject errors, but they are random so it's hard to get reproduceable results.
With BPF we can add determinism to our error injection. We can use kprobes and
other things to verify we are injecting errors at the exact case we are trying
to test. This patch gives us the tool to actual do the error injection part.
It is very simple, we just set the return value of the pt_regs we're given to
whatever we provide, and then override the PC with a dummy function that simply
returns.
Right now this only works on x86, but it would be simple enough to expand to
other architectures. Thanks,
Josef
next reply other threads:[~2017-12-06 16:12 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-06 16:12 Josef Bacik [this message]
2017-12-06 16:12 ` [PATCH v8 1/5] add infrastructure for tagging functions as error injectable Josef Bacik
2017-12-06 16:12 ` [PATCH v8 2/5] btrfs: make open_ctree " Josef Bacik
2017-12-06 16:12 ` [PATCH v8 3/5] bpf: add a bpf_override_function helper Josef Bacik
2017-12-06 16:12 ` [PATCH v8 4/5] samples/bpf: add a test for bpf_override_return Josef Bacik
2017-12-06 16:12 ` [PATCH v8 5/5] btrfs: allow us to inject errors at io_ctl_init Josef Bacik
2017-12-08 15:35 ` [PATCH v8 0/5] Add the ability to do BPF directed error injection Daniel Borkmann
2017-12-08 20:24 ` Josef Bacik
2017-12-08 23:25 ` Daniel Borkmann
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=1512576737-9417-1-git-send-email-josef@toxicpanda.com \
--to=josef@toxicpanda.com \
--cc=ast@kernel.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--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