If the fuzzer crashes or hangs, LLVM spits out a file
containing the raw data input for the iteration that
caused the crash or hang. Add a -N option to
llvm_nvme_fuzz to allow the user to specify one of these
files. When specified, the fuzzer will only run one
iteration with that specific input data.
Signed-off-by: Jim Harris <james.r.harris@intel.com>
Change-Id: I0d86cca7b2a0b6eaee263665478c31ee4060a8b8
Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/12451
Community-CI: Broadcom CI <spdk-ci.pdl@broadcom.com>
Tested-by: SPDK CI Jenkins <sys_sgci@intel.com>
Reviewed-by: Ben Walker <benjamin.walker@intel.com>
Reviewed-by: Changpeng Liu <changpeng.liu@intel.com>
We do not want the fuzzing thread to compete with
one of the nvmf target cores - otherwise they will
keep preempting each other and drastically reducing
the operation rate.
This sped up the operation rate approximately 20x
in my test VM.
Signed-off-by: Jim Harris <james.r.harris@intel.com>
Change-Id: I75d8c59d75e49cafaf7ee94f4796f9184b690647
Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/12403
Tested-by: SPDK CI Jenkins <sys_sgci@intel.com>
Reviewed-by: Dong Yi <dongx.yi@intel.com>
Reviewed-by: Ben Walker <benjamin.walker@intel.com>
Reviewed-by: Changpeng Liu <changpeng.liu@intel.com>
Community-CI: Broadcom CI <spdk-ci.pdl@broadcom.com>
If an input causes a hang, the fuzzing thread won't
terminate itself, since it is waiting for all
outstanding commands to complete. So raise a SIGSEGV
in the SPDK shutdown handler instead, which will
cause the fuzzer thread to exit as well as generating
an input file of the hung input.
Signed-off-by: Jim Harris <james.r.harris@intel.com>
Change-Id: I5753977740e27ca7827222b9e3cee1e939ef31a1
Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/12407
Tested-by: SPDK CI Jenkins <sys_sgci@intel.com>
Community-CI: Broadcom CI <spdk-ci.pdl@broadcom.com>
Reviewed-by: Ben Walker <benjamin.walker@intel.com>
Reviewed-by: Changpeng Liu <changpeng.liu@intel.com>
Reviewed-by: <yifan.bian@intel.com>
Reviewed-by: Dong Yi <dongx.yi@intel.com>
When the LLVM fuzzer is done, it calls exit(0)
explicitly. This triggers the DPDK exit handler
to run which starts unmapping huge pages while
our reactor thread is still running.
Currently, this doesn't cause any problems since
the fuzzing thread and reactor thread are running
on the same core. But the next patch will
unaffinitize the fuzzing thread, meaning that the
reactor thread will be actively trying to read
hugepage memory while the fuzzing thread is in
DPDK exit handlers unmapping that same memory.
Signed-off-by: Jim Harris <james.r.harris@intel.com>
Change-Id: Ie304ebbb1962855796dac699849a0726cfdcd0d4
Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/12406
Tested-by: SPDK CI Jenkins <sys_sgci@intel.com>
Community-CI: Broadcom CI <spdk-ci.pdl@broadcom.com>
Reviewed-by: Ben Walker <benjamin.walker@intel.com>
Reviewed-by: John Kariuki <John.K.Kariuki@intel.com>
Reviewed-by: Changpeng Liu <changpeng.liu@intel.com>
When we use Fuzzer 0 to do random testing of admin commands,
it's should be a normal one, instead of Fused operation.
Change-Id: I652a725798e79842866be01119be817c965fcee7
Signed-off-by: Yifan Bian <yifan.bian@intel.com>
Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/12421
Tested-by: SPDK CI Jenkins <sys_sgci@intel.com>
Community-CI: Broadcom CI <spdk-ci.pdl@broadcom.com>
Reviewed-by: Jim Harris <james.r.harris@intel.com>
Reviewed-by: Tomasz Zawadzki <tomasz.zawadzki@intel.com>
When doing ADMIN fuzz tests, the NVME_OPC_FABRIC is special for
fabric transports, so here we pick up a different one.
Change-Id: I00376c08eb9eabdb109656d631615eeb37c9d09c
Signed-off-by: Changpeng Liu <changpeng.liu@intel.com>
Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/10847
Reviewed-by: Ben Walker <benjamin.walker@intel.com>
Reviewed-by: Jim Harris <james.r.harris@intel.com>
Reviewed-by: Dong Yi <dongx.yi@intel.com>
Community-CI: Broadcom CI <spdk-ci.pdl@broadcom.com>
Tested-by: SPDK CI Jenkins <sys_sgci@intel.com>
Also name the fuzzer test case with `fuzz_admin` prefix
for ADMIN commands.
Change-Id: I6e5eeb71a5f795fee8afba034f3ad436220e3c20
Signed-off-by: Changpeng Liu <changpeng.liu@intel.com>
Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/10815
Community-CI: Broadcom CI <spdk-ci.pdl@broadcom.com>
Tested-by: SPDK CI Jenkins <sys_sgci@intel.com>
Reviewed-by: Jim Harris <james.r.harris@intel.com>
Reviewed-by: Tomasz Zawadzki <tomasz.zawadzki@intel.com>
LLVM provides libFuzzer which does coverage-guided
fuzzing of a library or application under test. For
SPDK, we can use this as a new and better way to
generate random commands to the SPDK nvmf target.
By default, libFuzzer provides the main() and your
source file just provides the function called by
LLVM for each iteration of random data. But this
doesn't really work for SPDK since we need to start
the app framework and the nvmf target. So we
specify -fsanitizer=fuzzer-no-link, explicitly
specify the location of the fuzzer_no_main library
and then call LLVMFuzzerRunDriver to start the
fuzzing process once we are ready.
Since this is all coverage-guided, we invoke the
fuzzer inside the nvmf target application. So this
patch creates a new target application called
'llvm_nvme_fuzz'. One core is needed to run the
nvmf target, then we spawn a pthread to run the
fuzzer against it.
Currently there are two fuzzers defined. Fuzzer 0
does random testing of admin commands. Fuzzer 1
is focused solely on GET_LOG_PAGE and fuzzes a
smaller subset of the bytes in the spdk_nvme_cmd.
Additional fuzzers can be added in the future for
other commands, testing I/O queues, data payloads,
etc.
You do need to specify CC and CXX when running
configure, as well as specify the location of the
special clang_rt.fuzz_no_main library. The path of
that library is dependent on your clang version and
architecture. If using clang-12 on x86_64 platform,
it will look like:
CC=clang-12 CXX=clang++-12 ./configure --with-fuzzer= \
/usr/lib/llvm-12/lib/clang/12.0.0/lib/linux/libclang_rt.fuzzer_no_main-x86_64.a
Then just do the following to demonstrate the fuzzer
tool.
make
test/nvmf/target/llvm_nvme_fuzz.sh --time=60 --fuzzer=0
Signed-off-by: Jim Harris <james.r.harris@intel.com>
Change-Id: Iee0997501893ac284a3947a1db7a155c5ceb7849
Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/10038
Reviewed-by: Changpeng Liu <changpeng.liu@intel.com>
Reviewed-by: Ben Walker <benjamin.walker@intel.com>
Tested-by: SPDK CI Jenkins <sys_sgci@intel.com>
