nvme: tcp: fix compile-time checks for TLS mode
authorArnd Bergmann <arnd@arndb.de>
Wed, 22 Nov 2023 22:47:19 +0000 (23:47 +0100)
committerJens Axboe <axboe@kernel.dk>
Thu, 23 Nov 2023 01:41:14 +0000 (18:41 -0700)
commit0e6c4fe782e683ff55a27fbb10e9c6b5c241533b
tree47e87f769b991131d402521ddccaf016f68c41d0
parent65e2a74c44ddfa174b700f5da2d1d29b4ba6639b
nvme: tcp: fix compile-time checks for TLS mode

When CONFIG_NVME_KEYRING is enabled as a loadable module, but the TCP
host code is built-in, it fails to link:

arm-linux-gnueabi-ld: drivers/nvme/host/tcp.o: in function `nvme_tcp_setup_ctrl':
tcp.c:(.text+0x1940): undefined reference to `nvme_tls_psk_default'

The problem is that the compile-time conditionals are inconsistent here,
using a mix of #ifdef CONFIG_NVME_TCP_TLS, IS_ENABLED(CONFIG_NVME_TCP_TLS)
and IS_ENABLED(CONFIG_NVME_KEYRING) checks, with CONFIG_NVME_KEYRING
controlling whether the implementation is actually built.

Change it to use IS_ENABLED(CONFIG_NVME_KEYRING) checks consistently,
which should help readability and make it less error-prone. Combining
it with the check for the ctrl->opts->tls flag lets the compiler drop
all the TLS code in configurations without this feature, which also
helps runtime behavior in addition to avoiding the link failure.

To make it possible for the compiler to build the dead code, both
the tls_handshake_timeout variable and the TLS specific members
of nvme_tcp_queue need to be moved out of the #ifdef block as well,
but at least the former of these gets optimized out again.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20231122224719.4042108-4-arnd@kernel.org
Signed-off-by: Jens Axboe <axboe@kernel.dk>
drivers/nvme/host/tcp.c