[PATCH] nvmet-tcp: do not try to cancel uninitialized tls_handshake_tmo_work

[PATCH] nvmet-tcp: do not try to cancel uninitialized tls_handshake_tmo_work

[Hannes Reinecke]

The TLS handshake timeout workqueue is only initialized if TLS
is configured, so we shouldn't try to de-initialize it
unconditionally.

Suggested-by: Maurizio Lombardi <mlombard@redhat.com>
Signed-off-by: Hannes Reinecke <hare@suse.de>
---
 drivers/nvme/target/tcp.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/nvme/target/tcp.c b/drivers/nvme/target/tcp.c
index 4336fe048e43..e155bcaa42fa 100644
--- a/drivers/nvme/target/tcp.c
+++ b/drivers/nvme/target/tcp.c
@@ -1587,7 +1587,9 @@ static void nvmet_tcp_release_queue_work(struct work_struct *w)
 	mutex_unlock(&nvmet_tcp_queue_mutex);
 
 	nvmet_tcp_restore_socket_callbacks(queue);
+#ifdef CONFIG_NVME_TARGET_TCP_TLS
 	cancel_delayed_work_sync(&queue->tls_handshake_tmo_work);
+#endif
 	cancel_work_sync(&queue->io_work);
 	/* stop accepting incoming data */
 	queue->rcv_state = NVMET_TCP_RECV_ERR;
-- 
2.35.3

Re: [PATCH] nvmet-tcp: do not try to cancel uninitialized tls_handshake_tmo_work

[Jens Axboe]

On 10/19/23 6:53 AM, Hannes Reinecke wrote:
> The TLS handshake timeout workqueue is only initialized if TLS
> is configured, so we shouldn't try to de-initialize it
> unconditionally.

What about the one in nvmet_tcp_tls_handshake_done()?

Please include a fixes line.

-- 
Jens Axboe

Re: [PATCH] nvmet-tcp: do not try to cancel uninitialized tls_handshake_tmo_work

[Hannes Reinecke]

On 10/19/23 15:01, Jens Axboe wrote:
> On 10/19/23 6:53 AM, Hannes Reinecke wrote:
>> The TLS handshake timeout workqueue is only initialized if TLS
>> is configured, so we shouldn't try to de-initialize it
>> unconditionally.
> 
> What about the one in nvmet_tcp_tls_handshake_done()?
> 
That already is encapsulated by the config variable, so nothing to be 
done here.

> Please include a fixes line.
> 
Oh, sure.

Cheers,

Hannes