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

[Daniel Wagner]

On Thu, Nov 16, 2023 at 03:03:20AM +0000, Shinichiro Kawasaki wrote:
> > 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?

Yes. The whole point of adding the features to /dev/nvme-fabrics is that
we can figure out easily what is supported. If dhchap_ctrl_secret is not
working due missing CONFIG_NVME_HOST_AUTH, then it should not be in the
list.

> > 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.

I'd rather see this fixed as pointed out above. This is a lot of
overhead to figure out if something is supported.

Thanks,
Daniel