[PATCH blktests 2/2] nvme/{041,042,043,044,045}: require kernel config NVME_HOST_AUTH

[Hannes Reinecke]

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 at suse.de                              +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