From: Christoph Hellwig <hch@lst.de>
To: alistair23@gmail.com
Cc: chuck.lever@oracle.com, hare@kernel.org,
kernel-tls-handshake@lists.linux.dev, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
linux-nvme@lists.infradead.org, linux-nfs@vger.kernel.org,
kbusch@kernel.org, axboe@kernel.dk, hch@lst.de, sagi@grimberg.me,
kch@nvidia.com, hare@suse.de,
Alistair Francis <alistair.francis@wdc.com>
Subject: Re: [PATCH v5 6/6] nvmet-tcp: Support KeyUpdate
Date: Wed, 12 Nov 2025 08:01:38 +0100 [thread overview]
Message-ID: <20251112070138.GG4873@lst.de> (raw)
In-Reply-To: <20251112042720.3695972-7-alistair.francis@wdc.com>
On Wed, Nov 12, 2025 at 02:27:20PM +1000, alistair23@gmail.com wrote:
> From: Alistair Francis <alistair.francis@wdc.com>
>
> If the nvmet_tcp_try_recv() function return EKEYEXPIRED or if we receive
> a KeyUpdate handshake type then the underlying TLS keys need to be
> updated.
>
> If the NVMe Host (TLS client) initiates a KeyUpdate this patch will
> allow the NVMe layer to process the KeyUpdate request and forward the
> request to userspace. Userspace must then update the key to keep the
> connection alive.
>
> This patch allows us to handle the NVMe host sending a KeyUpdate
> request without aborting the connection. At this time we don't support
> initiating a KeyUpdate.
>
> Link: https://datatracker.ietf.org/doc/html/rfc8446#section-4.6.3
> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
> Reviewed-by: Hannes Reinecke <hare@suse.de>
> ---
> v5:
> - No change
> v4:
> - Restructure code to avoid #ifdefs and forward declarations
> - Use a helper function for checking -EKEYEXPIRED
> - Remove all support for initiating KeyUpdate
> - Use helper function for restoring callbacks
> v3:
> - Use a write lock for sk_user_data
> - Fix build with CONFIG_NVME_TARGET_TCP_TLS disabled
> - Remove unused variable
> v2:
> - Use a helper function for KeyUpdates
> - Ensure keep alive timer is stopped
> - Wait for TLS KeyUpdate to complete
>
> drivers/nvme/target/tcp.c | 203 ++++++++++++++++++++++++++------------
> 1 file changed, 142 insertions(+), 61 deletions(-)
>
> diff --git a/drivers/nvme/target/tcp.c b/drivers/nvme/target/tcp.c
> index 818efdeccef1..486ea7bb0056 100644
> --- a/drivers/nvme/target/tcp.c
> +++ b/drivers/nvme/target/tcp.c
> @@ -175,6 +175,7 @@ struct nvmet_tcp_queue {
>
> /* TLS state */
> key_serial_t tls_pskid;
> + key_serial_t handshake_session_id;
> struct delayed_work tls_handshake_tmo_work;
>
> unsigned long poll_end;
> @@ -186,6 +187,8 @@ struct nvmet_tcp_queue {
> struct sockaddr_storage sockaddr_peer;
> struct work_struct release_work;
>
> + struct completion tls_complete;
> +
> int idx;
> struct list_head queue_list;
>
> @@ -214,6 +217,10 @@ static struct workqueue_struct *nvmet_tcp_wq;
> static const struct nvmet_fabrics_ops nvmet_tcp_ops;
> static void nvmet_tcp_free_cmd(struct nvmet_tcp_cmd *c);
> static void nvmet_tcp_free_cmd_buffers(struct nvmet_tcp_cmd *cmd);
> +#ifdef CONFIG_NVME_TARGET_TCP_TLS
> +static int nvmet_tcp_tls_handshake(struct nvmet_tcp_queue *queue,
> + enum handshake_key_update_type keyupdate);
> +#endif
>
> static inline u16 nvmet_tcp_cmd_tag(struct nvmet_tcp_queue *queue,
> struct nvmet_tcp_cmd *cmd)
> @@ -832,6 +839,23 @@ static int nvmet_tcp_try_send_one(struct nvmet_tcp_queue *queue,
> return 1;
> }
>
> +#ifdef CONFIG_NVME_TARGET_TCP_TLS
> +static bool nvmet_tls_key_expired(struct nvmet_tcp_queue *queue, int ret)
> +{
> + if (ret == -EKEYEXPIRED &&
> + queue->state != NVMET_TCP_Q_DISCONNECTING &&
> + queue->state != NVMET_TCP_Q_TLS_HANDSHAKE)
> + return true;
> +
> + return false;
Extra indentation before the return true. This could also be simplified
down to
return ret == -EKEYEXPIRED &&
queue->state != NVMET_TCP_Q_DISCONNECTING &&
queue->state != NVMET_TCP_Q_TLS_HANDSHAKE;
or if you want to do away with the ifdef entirely:
return IS_ENABLED(CONFIG_NVME_TARGET_TCP_TLS) &&
ret == -EKEYEXPIRED &&
queue->state != NVMET_TCP_Q_DISCONNECTING &&
queue->state != NVMET_TCP_Q_TLS_HANDSHAKE;
Othwise looks good.
prev parent reply other threads:[~2025-11-12 7:01 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-12 4:27 [PATCH v5 0/6] nvme-tcp: Support receiving KeyUpdate requests alistair23
2025-11-12 4:27 ` [PATCH v5 1/6] net/handshake: Store the key serial number on completion alistair23
2025-11-12 15:02 ` Chuck Lever
2025-11-30 22:21 ` Sagi Grimberg
2025-11-12 4:27 ` [PATCH v5 2/6] net/handshake: Define handshake_sk_destruct_req alistair23
2025-11-12 15:47 ` Chuck Lever
2025-11-13 10:19 ` Alistair Francis
2025-11-13 14:01 ` Chuck Lever
2025-11-13 14:37 ` Chuck Lever
2025-11-14 3:44 ` Alistair Francis
2025-11-14 14:14 ` Chuck Lever
2025-11-19 0:45 ` Alistair Francis
2025-11-20 13:51 ` Chuck Lever
2025-11-25 5:00 ` Alistair Francis
2025-11-25 13:55 ` Chuck Lever
2025-11-12 4:27 ` [PATCH v5 3/6] net/handshake: Ensure the request is destructed on completion alistair23
2025-11-12 4:27 ` [PATCH v5 4/6] net/handshake: Support KeyUpdate message types alistair23
2025-11-12 15:49 ` Chuck Lever
2025-11-13 2:16 ` Alistair Francis
2025-11-13 14:41 ` Chuck Lever
2025-11-27 13:12 ` Hannes Reinecke
2025-11-12 4:27 ` [PATCH v5 5/6] nvme-tcp: Support KeyUpdate alistair23
2025-11-12 6:59 ` Christoph Hellwig
2025-11-12 14:31 ` Chuck Lever
2025-11-12 14:38 ` Christoph Hellwig
2025-11-12 14:38 ` Chuck Lever
2025-11-27 13:31 ` Hannes Reinecke
2025-12-01 4:18 ` Alistair Francis
2025-12-01 15:03 ` Hannes Reinecke
2025-11-30 22:31 ` Sagi Grimberg
2025-12-01 23:27 ` Alistair Francis
2025-11-12 4:27 ` [PATCH v5 6/6] nvmet-tcp: " alistair23
2025-11-12 7:01 ` Christoph Hellwig [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20251112070138.GG4873@lst.de \
--to=hch@lst.de \
--cc=alistair.francis@wdc.com \
--cc=alistair23@gmail.com \
--cc=axboe@kernel.dk \
--cc=chuck.lever@oracle.com \
--cc=hare@kernel.org \
--cc=hare@suse.de \
--cc=kbusch@kernel.org \
--cc=kch@nvidia.com \
--cc=kernel-tls-handshake@lists.linux.dev \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=netdev@vger.kernel.org \
--cc=sagi@grimberg.me \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.