From: Akinobu Mita <akinobu.mita@gmail.com>
To: chaitanyak@nvidia.com
Cc: akinobu.mita@gmail.com, akpm@linux-foundation.org,
axboe@kernel.dk, hch@infradead.org, linux-block@vger.kernel.org,
linux-kernel@vger.kernel.org, shinichiro.kawasaki@wdc.com
Subject: [PATCH blktests] don't require modular null_blk for fault-injection
Date: Thu, 30 Mar 2023 01:21:45 +0900 [thread overview]
Message-ID: <20230329162145.147395-1-akinobu.mita@gmail.com> (raw)
In-Reply-To: <7c00f4f8-5bdf-4fa6-d9f0-141cf88c9ec9@nvidia.com>
I'm trying to allow configuration of null_blk fault-injection via configfs.
This blktests change changes null_blk fault-injection settings to be
configured via configfs instead of module parameters.
This allows null_blk fault-injection tests to run even if the null_blk is
built-in the kernel and not built as a module.
However, to keep the scripts simple, we will skip testing if the null_blk
does not yet support configuring fault-injection via configfs.
Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
---
tests/block/014 | 18 ++++++++++++------
tests/block/015 | 18 ++++++++++++------
tests/block/030 | 26 +++++++++++++++-----------
3 files changed, 39 insertions(+), 23 deletions(-)
diff --git a/tests/block/014 b/tests/block/014
index facd4bc..65913e5 100755
--- a/tests/block/014
+++ b/tests/block/014
@@ -16,20 +16,26 @@ requires() {
test() {
echo "Running ${TEST_NAME}"
- # The format is "<interval>,<probability>,<space>,<times>". Here, we
- # fail 50% of I/Os.
- if ! _init_null_blk timeout='1,50,0,-1'; then
+ # Here, we fail 50% of I/Os.
+ if ! _configure_null_blk faultb0 timeout_inject/probability=50 \
+ timeout_inject/times=-1 timeout_inject/verbose=0 power=1; then
+ if [[ -d /sys/kernel/config/nullb/faultb0/timeout_inject ]]; then
+ echo "Configuring null_blk failed"
+ else
+ SKIP_REASONS+=("requires fault injection via configfs")
+ fi
+ rmdir /sys/kernel/config/nullb/faultb0
return 1
fi
- for sched in $(_io_schedulers nullb0); do
+ for sched in $(_io_schedulers faultb0); do
echo "Testing $sched" >> "$FULL"
- echo "$sched" > /sys/block/nullb0/queue/scheduler
+ echo "$sched" > /sys/block/faultb0/queue/scheduler
# Do a bunch of I/Os which will timeout and then complete. The
# only thing we're really testing here is that this doesn't
# crash or hang.
for ((i = 0; i < 100; i++)); do
- dd if=/dev/nullb0 of=/dev/null bs=4K count=4 \
+ dd if=/dev/faultb0 of=/dev/null bs=4K count=4 \
iflag=direct status=none > /dev/null 2>&1 &
done
wait
diff --git a/tests/block/015 b/tests/block/015
index 389c67f..5257d33 100755
--- a/tests/block/015
+++ b/tests/block/015
@@ -18,16 +18,22 @@ requires() {
test() {
echo "Running ${TEST_NAME}"
- # The format is "<interval>,<probability>,<space>,<times>". Here, we
- # requeue 10% of the time.
- if ! _init_null_blk requeue='1,10,0,-1'; then
+ # Here, we requeue 10% of the time.
+ if ! _configure_null_blk faultb0 requeue_inject/probability=10 \
+ requeue_inject/times=-1 requeue_inject/verbose=0 power=1; then
+ if [[ -d /sys/kernel/config/nullb/faultb0/requeue_inject ]]; then
+ echo "Configuring null_blk failed"
+ else
+ SKIP_REASONS+=("requires fault injection via configfs")
+ fi
+ rmdir /sys/kernel/config/nullb/faultb0
return 1
fi
- for sched in $(_io_schedulers nullb0); do
+ for sched in $(_io_schedulers faultb0); do
echo "Testing $sched" >> "$FULL"
- echo "$sched" > /sys/block/nullb0/queue/scheduler
- dd if=/dev/nullb0 of=/dev/null bs=4K count=$((512 * 1024)) \
+ echo "$sched" > /sys/block/faultb0/queue/scheduler
+ dd if=/dev/faultb0 of=/dev/null bs=4K count=$((512 * 1024)) \
iflag=direct status=none
done
diff --git a/tests/block/030 b/tests/block/030
index 7a0712b..f3cc337 100755
--- a/tests/block/030
+++ b/tests/block/030
@@ -17,19 +17,23 @@ requires() {
}
test() {
- local i sq=/sys/kernel/config/nullb/nullb0/submit_queues
+ local i sq=/sys/kernel/config/nullb/faultb0/submit_queues
: "${TIMEOUT:=30}"
- # Legend: init_hctx=<interval>,<probability>,<space>,<times>
# Set <space> to $(nproc) + 1 to make loading of null_blk succeed.
- if ! _init_null_blk nr_devices=0 \
- "init_hctx=$(nproc),100,$(($(nproc) + 1)),-1"; then
- echo "Loading null_blk failed"
- return 1
- fi
- if ! _configure_null_blk nullb0 completion_nsec=0 blocksize=512 size=16\
- submit_queues="$(nproc)" memory_backed=1 power=1; then
- echo "Configuring null_blk failed"
+ if ! _configure_null_blk faultb0 completion_nsec=0 blocksize=512 size=16\
+ submit_queues="$(nproc)" memory_backed=1 \
+ init_hctx_fault_inject/interval="$(nproc)" \
+ init_hctx_fault_inject/probability=100 \
+ init_hctx_fault_inject/space="$(($(nproc) + 1))" \
+ init_hctx_fault_inject/times=-1 \
+ init_hctx_fault_inject/verbose=0 power=1; then
+ if [[ -d /sys/kernel/config/nullb/faultb0/init_hctx_fault_inject ]]; then
+ echo "Configuring null_blk failed"
+ else
+ SKIP_REASONS+=("requires fault injection via configfs")
+ fi
+ rmdir /sys/kernel/config/nullb/faultb0
return 1
fi
# Since older null_blk versions do not allow "submit_queues" to be
@@ -47,7 +51,7 @@ test() {
else
SKIP_REASONS+=("Skipping test because $sq cannot be modified")
fi
- rmdir /sys/kernel/config/nullb/nullb0
+ rmdir /sys/kernel/config/nullb/faultb0
_exit_null_blk
echo Passed
}
--
2.34.1
next prev parent reply other threads:[~2023-03-29 16:22 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-27 14:37 [PATCH 0/2] block: null_blk: make fault-injection configurable via configfs Akinobu Mita
2023-03-27 14:37 ` [PATCH 1/2] fault-inject: allow configuration " Akinobu Mita
2023-04-15 14:53 ` Geert Uytterhoeven
2023-04-15 16:50 ` Akinobu Mita
2023-03-27 14:37 ` [PATCH 2/2] block: null_blk: make fault-injection dynamically configurable per device Akinobu Mita
2023-03-27 22:13 ` [PATCH 0/2] block: null_blk: make fault-injection configurable via configfs Christoph Hellwig
2023-03-27 22:18 ` Chaitanya Kulkarni
2023-03-29 16:21 ` Akinobu Mita [this message]
2023-04-12 3:05 ` [PATCH blktests] don't require modular null_blk for fault-injection Shin'ichiro Kawasaki
2023-04-15 10:29 ` Akinobu Mita
2023-04-13 13:39 ` [PATCH 0/2] block: null_blk: make fault-injection configurable via configfs Jens Axboe
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=20230329162145.147395-1-akinobu.mita@gmail.com \
--to=akinobu.mita@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=axboe@kernel.dk \
--cc=chaitanyak@nvidia.com \
--cc=hch@infradead.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=shinichiro.kawasaki@wdc.com \
/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).