Commit cd42079f authored by Michal Berger's avatar Michal Berger Committed by Tomasz Zawadzki
Browse files

test/unit: Use --fair-sched under valgrind while executing cuse ut 



Without the proper serialization, it's been seen that under some
platforms this test tend to loop infinitely while checking the
g_device_fdgrp. Everything points at a potential issue with
valgrind's scheduler which in this case must guarantee fairness,
regardless of the potential performance penalty.

Change-Id: If21e56510b8ccccbe2935372908b75e53e44a4a6
Signed-off-by: default avatarMichal Berger <michal.berger@intel.com>
Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/22398


Tested-by: default avatarSPDK CI Jenkins <sys_sgci@intel.com>
Reviewed-by: default avatarKonrad Sztyber <konrad.sztyber@intel.com>
Reviewed-by: default avatarTomasz Zawadzki <tomasz.zawadzki@intel.com>
parent 192db8de

test/unit/unittest.sh

+2 −1
Original line number Diff line number Diff line
@@ -253,7 +253,8 @@ if grep -q '#define SPDK_CONFIG_RDMA 1' $rootdir/include/spdk/config.h; then 
fi



if grep -q '#define SPDK_CONFIG_NVME_CUSE 1' $rootdir/include/spdk/config.h; then

	run_test "unittest_nvme_cuse" $valgrind $testdir/lib/nvme/nvme_cuse.c/nvme_cuse_ut

	# See https://github.com/spdk/spdk/issues/3307 for rationale behind use of --fair-sched in this ut

	run_test "unittest_nvme_cuse" ${valgrind:+$valgrind --fair-sched=yes} "$testdir/lib/nvme/nvme_cuse.c/nvme_cuse_ut"

fi



run_test "unittest_nvmf" unittest_nvmf