This patch set makes null_blk driver-specific fault-injection dynamically
configurable per device via configfs.
Since the null_blk driver supports configuration such as device creation
via configfs, it is natural to configure fault-injection via configfs as
well.
Currently, only the debugfs interface is provided for dynamically
configuring fault-injection, so this introduces a compatible interface via
configfs.
Akinobu Mita (2):
fault-inject: allow configuration via configfs
block: null_blk: make fault-injection dynamically configurable per
device
.../fault-injection/fault-injection.rst | 8 +
drivers/block/null_blk/Kconfig | 2 +-
drivers/block/null_blk/main.c | 93 +++++++--
drivers/block/null_blk/null_blk.h | 7 +-
include/linux/fault-inject.h | 22 ++
lib/Kconfig.debug | 13 +-
lib/fault-inject.c | 191 ++++++++++++++++++
7 files changed, 312 insertions(+), 24 deletions(-)
--
2.34.1
On Mon, Mar 27, 2023 at 11:37:31PM +0900, Akinobu Mita wrote:
> This patch set makes null_blk driver-specific fault-injection dynamically
> configurable per device via configfs.
>
> Since the null_blk driver supports configuration such as device creation
> via configfs, it is natural to configure fault-injection via configfs as
> well.
>
> Currently, only the debugfs interface is provided for dynamically
> configuring fault-injection, so this introduces a compatible interface via
> configfs.
Oh, nice. Can you also update blktests to take advantage of this and
not require built-in null_blk for fault injection tests?
On 3/27/23 15:13, Christoph Hellwig wrote:
> On Mon, Mar 27, 2023 at 11:37:31PM +0900, Akinobu Mita wrote:
>> This patch set makes null_blk driver-specific fault-injection dynamically
>> configurable per device via configfs.
>>
>> Since the null_blk driver supports configuration such as device creation
>> via configfs, it is natural to configure fault-injection via configfs as
>> well.
>>
>> Currently, only the debugfs interface is provided for dynamically
>> configuring fault-injection, so this introduces a compatible interface via
>> configfs.
> Oh, nice. Can you also update blktests to take advantage of this and
> not require built-in null_blk for fault injection tests?
+1 on blktests, please CC me when you do.
-ck
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 <[email protected]>
---
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
Akinobu, thanks for the patch, and sorry for this slow response.
On Mar 30, 2023 / 01:21, Akinobu Mita wrote:
> 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.
It's good that the three test case can run with built-in null_blk.
>
> However, to keep the scripts simple, we will skip testing if the null_blk
> does not yet support configuring fault-injection via configfs.
Hmm, it means that blktests coverage will be lost on older kernels without the
configfs support. Before this change, the test cases were not skipped on older
kernel with loadable null_blk. After this patch, the test cases will be skipped.
Can we cover both the new and old ways? When the null_blk set up with configfs
fails, we can fallback to the old way with module parameters.
For example, null_blk set up of block/014 can be like this:
# 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 \
> /dev/null 2>&1; then
rmdir /sys/kernel/config/nullb/faultb0
if [[ -d /sys/kernel/config/nullb/faultb0/timeout_inject ]]; then
echo "Configuring null_blk failed"
return 1
elif _module_file_exists null_blk; then
# Fall back to set up with module parameter. The format
# is "<interval>,<probability>,<space>,<times>"
if ! _init_null_blk timeout='1,50,0,-1'; then
echo "Configuring null_blk failed"
return 1;
fi
else
SKIP_REASONS+=("requires fault injection via configfs or modular null_blk")
return 1
fi
fi
On Mon, 27 Mar 2023 23:37:31 +0900, Akinobu Mita wrote:
> This patch set makes null_blk driver-specific fault-injection dynamically
> configurable per device via configfs.
>
> Since the null_blk driver supports configuration such as device creation
> via configfs, it is natural to configure fault-injection via configfs as
> well.
>
> [...]
Applied, thanks!
[1/2] fault-inject: allow configuration via configfs
commit: 4668c7a2940d134bea50058e138591b97485c5da
[2/2] block: null_blk: make fault-injection dynamically configurable per device
commit: bb4c19e030f45c5416f1eb4daa94fbaf7165e9ea
Best regards,
--
Jens Axboe
2023年4月12日(水) 12:05 Shin'ichiro Kawasaki <[email protected]>:
>
> Akinobu, thanks for the patch, and sorry for this slow response.
>
> On Mar 30, 2023 / 01:21, Akinobu Mita wrote:
> > 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.
>
> It's good that the three test case can run with built-in null_blk.
>
> >
> > However, to keep the scripts simple, we will skip testing if the null_blk
> > does not yet support configuring fault-injection via configfs.
>
> Hmm, it means that blktests coverage will be lost on older kernels without the
> configfs support. Before this change, the test cases were not skipped on older
> kernel with loadable null_blk. After this patch, the test cases will be skipped.
>
> Can we cover both the new and old ways? When the null_blk set up with configfs
> fails, we can fallback to the old way with module parameters.
>
> For example, null_blk set up of block/014 can be like this:
OK, I'll update the tests and give it a try.