Re: [PATCH blktests] nvme/068: check module reference count with patience

On 05/08/2026 06:13, Shin'ichiro Kawasaki wrote:
> The test case nvme/068 fails depending on the system it runs on with the =
failure
> message below: nvme/068 (tr=3Drdma) (NVMe multipath delayed removal test)=
 [failed]
> runtime ..=E2=80=8A. 11.=E2=80=8A357s --- tests/nvme/068.=E2=80=8Aout 202=
6-08-03 17:=E2=80=8A24:=E2=80=8A32.=E2=80=8A394566266 +0000
>=20
>=20
> The test case nvme/068 fails depending on the system it runs on with
> the failure message below:
>=20
>      nvme/068 (tr=3Drdma) (NVMe multipath delayed removal test)     [fail=
ed]
>          runtime    ...  11.357s
>          --- tests/nvme/068.out    2026-08-03 17:24:32.394566266 +0000
>          +++ /home/runner/blktests/results/nodev_tr_rdma/nvme/068.out.bad=
  2026-08-03 18:15:17.461243816 +0000
>          @@ -1,3 +1,4 @@
>           Running nvme/068
>           pwrite: Input/output error
>          +module refcount not as original
>           Test complete
>=20
> The test case checks the reference count of the nvme_core module. If the
> count is not the expected value, it fails with the error message.
> However, when the test system is slow, it takes some time until the
> reference count gets updated. When the check is too early, the count
> mismatch happens. To avoid the unexpected failure, repeat the reference
> count check.
>=20
> Signed-off-by: Shin'ichiro Kawasaki <[email protected]>
> ---
> I ran the test case nvme/068 with the patch using the kernel that does
> not include the commit below:
>=20
>     3f150f0f010f ("nvme-multipath: put module reference when delayed remo=
val work is canceled")
>=20
> And I observed the test case failed. When the kernel includes the commit,
> the test case passes. This indicates the patch does not break the
> reference count sanity check capability of the test case.
>=20
>    tests/nvme/068 | 16 ++++++++++++++--
>    1 file changed, 14 insertions(+), 2 deletions(-)
>=20
> diff --git a/tests/nvme/068 b/tests/nvme/068
> index 4aee95b..7e39e17 100755
> --- a/tests/nvme/068
> +++ b/tests/nvme/068
> @@ -27,6 +27,19 @@ _delayed_nvme_reconnect_ctrl() {
>    	_nvme_connect_subsys
>    }
>   =20
> +_check_nvme_core_ref_count() {
> +	local refcnt i
> +
> +	for ((i =3D 0; i < 10; i++)); do
> +		refcnt=3D$(_module_use_count nvme_core)
> +		if [ "$refcnt" !=3D "" ] && [ "$refcnt" -eq "$refcnt_orig" ]; then

As I remember, $refcnt =3D=3D "" happens when the driver is built-in. So=20
should we just always return 0 immediately when we find this?

> +			return

return 0?

> +		fi
> +		sleep 1
> +	done
> +	return 1
> +}
> +
>    test() {
>    	echo "Running ${TEST_NAME}"
>   =20
> @@ -98,8 +111,7 @@ test() {
>    	if ! _nvmf_wait_for_state "${def_subsysnqn}" "live" ; then
>    		echo "subsystem did not return"
>    	fi
> -	refcnt=3D$(_module_use_count nvme_core)
> -	if [ "$refcnt" !=3D "" ] && [ "$refcnt" -ne "$refcnt_orig" ]; then
> +	if ! _check_nvme_core_ref_count; then
>    		echo "module refcount not as original"
>    	fi
>   =20
> --=20
> 2.54.0
>=20