[blktests,v2,3/4] nvme/060: add test nvme fabrics target resetting during I/O

Commit Message

Daniel Wagner April 8, 2025, 4:25 p.m. UTC

Newer kernel support to reset the target via the debugfs. Add a new test
case which exercises this interface.

Reviewed-by: Chaitanya Kulkarni <[e-mail]>
Signed-off-by: Daniel Wagner <[e-mail]>
---
 tests/nvme/060     | 62 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
 tests/nvme/060.out |  2 ++
 2 files changed, 64 insertions(+)

Comments

Daniel Wagner April 9, 2025, 5:59 p.m. UTC | #1

On Tue, Apr 08, 2025 at 06:25:59PM +0200, Daniel Wagner wrote:
> +requires() {
> +	_nvme_requires
> +	_have_loop
> +	_require_nvme_trtype_is_fabrics
> +	_have_kernel_option NVME_TARGET_DEBUGF

Typo: s/NVME_TARGET_DEBUGF/NVME_TARGET_DEBUGFS/

Shinichiro Kawasaki April 14, 2025, 12:10 p.m. UTC | #2

On Apr 09, 2025 / 19:59, Daniel Wagner wrote:
> On Tue, Apr 08, 2025 at 06:25:59PM +0200, Daniel Wagner wrote:
> > +requires() {
> > +	_nvme_requires
> > +	_have_loop
> > +	_require_nvme_trtype_is_fabrics
> > +	_have_kernel_option NVME_TARGET_DEBUGF
> 
> Typo: s/NVME_TARGET_DEBUGF/NVME_TARGET_DEBUGFS/

I can fold in this change.

BTW, when I ran this test case for tr=loop, I observe the kernel
message reports "invalid parameter" errors as follows:

[  150.907272][ T2312] run blktests nvme/060 at 2025-04-14 20:59:00
[  150.947249][ T2367] loop0: detected capacity change from 0 to 2097152
[  150.959649][ T2370] nvmet: adding nsid 1 to subsystem blktests-subsystem-1
[  151.009708][ T2382] nvme_fabrics: invalid parameter 'reconnect_delay=%d'
[  155.626630][ T2429] nvme_fabrics: invalid parameter 'reconnect_delay=%d'
[  160.158015][ T2476] nvme_fabrics: invalid parameter 'reconnect_delay=%d'
[  164.745460][ T2523] nvme_fabrics: invalid parameter 'reconnect_delay=%d'
[  169.161893][ T2570] nvme_fabrics: invalid parameter 'reconnect_delay=%d'
[  173.766537][ T2619] nvme_fabrics: invalid parameter 'reconnect_delay=%d'

Is it expected?

This test case passes for other transports (rdma, tcp and fc) and they do not
trigger the error message above. My mere guess is that this case might not work
for the loop transport, and may need "_require_nvme_trtype tcp rdma fc" in same
manner as nvme/048.

Patch

diff --git a/tests/nvme/060 b/tests/nvme/060
new file mode 100755
index 0000000000000000000000000000000000000000..293b03cd0ef6a75722c6b86fccbbc931d6f5e3a1
--- /dev/null
+++ b/tests/nvme/060
@@ -0,0 +1,62 @@ 
+#!/bin/bash
+# SPDX-License-Identifier: GPL-3.0+
+# Copyright (C) 2025 Daniel Wagner, SUSE Labs
+#
+# Test nvme fabrics controller reset/disconnect/reconnect.
+
+. tests/nvme/rc
+
+DESCRIPTION="test nvme fabrics target reset"
+
+requires() {
+	_nvme_requires
+	_have_loop
+	_require_nvme_trtype_is_fabrics
+	_have_kernel_option NVME_TARGET_DEBUGF
+}
+
+set_conditions() {
+	_set_nvme_trtype "$@"
+}
+
+nvmet_debug_trigger_reset() {
+	local nvmet_subsystem="$1"
+	local dfs_path="${NVMET_DFS}/${nvmet_subsystem}"
+
+	find "${dfs_path}" -maxdepth 1 -type d -name 'ctrl*' -exec sh -c 'echo "fatal" > "$1/state"' _ {} \;
+}
+
+nvmet_reset_loop() {
+	while true; do
+		nvmet_debug_trigger_reset "${def_subsysnqn}"
+		sleep 2
+	done
+}
+
+test() {
+	echo "Running ${TEST_NAME}"
+
+	_setup_nvmet
+
+	_nvmet_target_setup
+
+	nvmet_reset_loop &
+	reset_loop_pid=$!
+
+	# Reset the host in different states e.g when the host is in the
+	# connected or connecting state.
+	#
+	# The target reset is triggered with an even number timeout, while the
+	# host reconnects with an odd number timeout.
+	for ((i = 0; i <= 5; i++)); do
+		_nvme_connect_subsys --keep-alive-tmo 1 --reconnect-delay 1
+		sleep 3
+		_nvme_disconnect_subsys >> "$FULL" 2>&1
+	done
+
+	{ kill "${reset_loop_pid}"; wait; } &> /dev/null
+
+	_nvmet_target_cleanup
+
+	echo "Test complete"
+}
diff --git a/tests/nvme/060.out b/tests/nvme/060.out
new file mode 100644
index 0000000000000000000000000000000000000000..517ff2dfcfd41c4088991e669af9fef52bde570b
--- /dev/null
+++ b/tests/nvme/060.out
@@ -0,0 +1,2 @@ 
+Running nvme/060
+Test complete