On 11/16/23 04:03, Shinichiro Kawasaki wrote:
On Nov 16, 2023 / 02:09, Shinichiro Kawasaki wrote:
On Nov 15, 2023 / 15:32, Hannes Reinecke wrote:
On 11/15/23 15:18, Daniel Wagner wrote:
[...]
diff --git a/tests/nvme/045 b/tests/nvme/045
index 1eb1032a3b93..954f96bedd5a 100755
--- a/tests/nvme/045
+++ b/tests/nvme/045
@@ -17,6 +17,7 @@ requires() {
_have_kernel_option NVME_TARGET_AUTH
_require_nvme_trtype_is_fabrics
_require_nvme_cli_auth
+ _require_kernel_nvme_feature dhchap_ctrl_secret
The idea looked good and I checked /dev/nvme-fabrics content on kernel v6.7-
rc1. But unfortunately, I found that /dev/nvme-fabrics content is same
regardless of the kernel config NVME_HOST_AUTH. I checked opt_tokens in
drivers/nvme/host/fabrics.c, and saw that "dhchap_ctrl_secret=%s" is not
surrounded with #ifdef CONFIG_NVME_HOST_AUTH. Should we add the #ifdef?
I tried to find out other differences that NVME_HOST_AUTH makes and visible
from userland. I found ctrl_dhchap_secret sysfs attribute of nvme devices is
in #ifdef CONFIG_HOST_AUTH. But to find the attribute, it looks "nvme connect"
needs to happen before-hand. So the attribute does not look usable. Hmm.
I rethought about the ctrl_dhchap_secret sysfs attribute, and came up with an
idea to set up nvme target without host key and do "nvme connect". (With host
key, nvme connect fails). Then check if the sysfs attributes exists or not.
I quickly created a patch below, and it looks working. The check creates a nvme
target and affects the test system, then I think it should be done in test()
rather than requires(). If there is no better idea, we can take this solution.
diff --git a/tests/nvme/041 b/tests/nvme/041
index d23f10a..28322e4 100755
--- a/tests/nvme/041
+++ b/tests/nvme/041
@@ -27,6 +27,10 @@ test() {
local hostkey
local ctrldev
+ if ! _nvme_host_supports_dhchap_ctrl_secret; then
+ return 1
+ fi
+
hostkey="$(nvme gen-dhchap-key -n ${def_subsysnqn} 2> /dev/null)"
if [ -z "$hostkey" ] ; then
echo "nvme gen-dhchap-key failed"
diff --git a/tests/nvme/rc b/tests/nvme/rc
index 1cff522..9e77d7a 100644
--- a/tests/nvme/rc
+++ b/tests/nvme/rc
@@ -1010,3 +1010,21 @@ _nvme_reset_ctrl() {
_nvme_delete_ctrl() {
echo 1 > /sys/class/nvme/"$1"/delete_controller
}
+
+# Set up nvme target without hostkey and see if dhchap_ctrl_secret exists.
+_nvme_host_supports_dhchap_ctrl_secret() {
+ local ctrldev
+ local ret=0
+
+ _nvmet_target_setup --hostkey ""
+ _nvme_connect_subsys "${nvme_trtype}" "${def_subsysnqn}"
+ cdev=$(_find_nvme_dev "${def_subsysnqn}")
+ if [[ -z $cdev || ! -e "/sys/class/nvme/${cdev}/dhchap_ctrl_secret" ]]; then
+ ret=1
+ SKIP_REASONS+=("dhchap_ctrl_secret is not enabled (check CONFIG_NVME_HOST_AUTH)")
+ fi
+ _nvme_disconnect_subsys "${def_subsysnqn}" > /dev/null 2>&1
+ _nvmet_target_cleanup
+
+ return $ret
+}
Errm. Not quite what I had in mind.
To step back a bit: why again do you want to run these tests on older
kernels? If authentication is not present it's _quite_ pointless running
them...
So what's the rationale?
Cheers,
Hannes
--
Dr. Hannes Reinecke Kernel Storage Architect
hare@xxxxxxx +49 911 74053 688
SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), Geschäftsführer: Ivo Totev, Andrew
Myers, Andrew McDonald, Martje Boudien Moerman
