linux-block.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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


  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).