From: David Laight <david.laight.linux@gmail.com>
To: Martin Belanger via B4 Relay
<devnull+martin.nvme.dev.gmail.com@kernel.org>
Cc: martin.nvme.dev@gmail.com, Keith Busch <kbusch@kernel.org>,
Jens Axboe <axboe@kernel.dk>, Christoph Hellwig <hch@lst.de>,
Sagi Grimberg <sagi@grimberg.me>,
Hannes Reinecke <hare@kernel.org>,
linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org,
Martin Belanger <martin.belanger@dell.com>,
stable@vger.kernel.org
Subject: Re: [PATCH v2 1/3] nvme-tcp: use an aligned buffer for the TLS record type
Date: Thu, 12 Nov 2026 22:37:07 +0000 [thread overview]
Message-ID: <20261112223707.3bf1e1a6@pumpkin> (raw)
In-Reply-To: <20261111-nvme-tcp-live-ctrlrec-v2-1-6295202b84de@gmail.com>
On Wed, 11 Nov 2026 15:42:39 -0500
Martin Belanger via B4 Relay <devnull+martin.nvme.dev.gmail.com@kernel.org> wrote:
> From: Martin Belanger <martin.belanger@dell.com>
>
> The buffers that receive the TLS record type are char arrays.
> put_cmsg() and tls_get_record_type() access them as struct cmsghdr,
> which needs a stricter alignment than a char array has.
>
> Use a union with struct cmsghdr, sized with CMSG_SPACE(), as
> svc_tcp_recv_cmsg() and xs_tls_read_record() in sunrpc do.
>
> Fixes: 2837966ab2a8 ("nvme-tcp: control message handling for recvmsg()")
> Cc: stable@vger.kernel.org
> Signed-off-by: Martin Belanger <martin.belanger@dell.com>
> ---
> drivers/nvme/host/tcp.c | 23 ++++++++++++++---------
> 1 file changed, 14 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/nvme/host/tcp.c b/drivers/nvme/host/tcp.c
> index 7ecc6c007f8d..749d77b4e172 100644
> --- a/drivers/nvme/host/tcp.c
> +++ b/drivers/nvme/host/tcp.c
> @@ -77,6 +77,12 @@ MODULE_PARM_DESC(tls_handshake_timeout,
> /* TLS records read while waiting for the ICResp, the ICResp included */
> #define NVME_TCP_ICRESP_MAX_RECORDS 8
>
> +/* control message buffer for the TLS record type */
> +union nvme_tcp_tls_cmsg {
> + struct cmsghdr cmsg;
> + u8 buf[CMSG_SPACE(sizeof(u8))];
> +};
> +
> static int nvme_tcp_cpu_queues[NR_CPUS];
> static DEFINE_SPINLOCK(nvme_tcp_cpu_queues_lock);
>
> @@ -1653,11 +1659,11 @@ static int nvme_tcp_skip_tls_record(struct nvme_tcp_queue *queue,
> .iov_base = buf,
> .iov_len = sizeof(buf),
> };
> - char cbuf[CMSG_LEN(sizeof(char))] = {};
> + union nvme_tcp_tls_cmsg u = {};
Is that right?
You are changing something that was CMSG_LEN(1) to one of CMSG_SPACE(1).
I've a feeling it would be right if it was a struct, not a union.
Did you test it?
Or even compile it and compare the two object files.
David
> /* kTLS fails a control record read without a cmsg buffer */
> struct msghdr drain = {
> - .msg_control = cbuf,
> - .msg_controllen = sizeof(cbuf),
> + .msg_control = &u,
> + .msg_controllen = sizeof(u),
> };
>
> ret = kernel_recvmsg(queue->sock, &drain, &iov, 1, sizeof(buf),
> @@ -1682,7 +1688,7 @@ static int nvme_tcp_skip_tls_record(struct nvme_tcp_queue *queue,
> static int nvme_tcp_recv_icresp(struct nvme_tcp_queue *queue,
> struct nvme_tcp_icresp_pdu *icresp)
> {
> - char cbuf[CMSG_LEN(sizeof(char))];
> + union nvme_tcp_tls_cmsg u;
> struct msghdr msg;
> struct kvec iov;
> u8 ctype;
> @@ -1690,12 +1696,12 @@ static int nvme_tcp_recv_icresp(struct nvme_tcp_queue *queue,
>
> for (i = 0; i < NVME_TCP_ICRESP_MAX_RECORDS; i++) {
> memset(&msg, 0, sizeof(msg));
> - memset(cbuf, 0, sizeof(cbuf));
> + memset(&u, 0, sizeof(u));
> iov.iov_base = icresp;
> iov.iov_len = sizeof(*icresp);
> if (nvme_tcp_queue_tls(queue)) {
> - msg.msg_control = cbuf;
> - msg.msg_controllen = sizeof(cbuf);
> + msg.msg_control = &u;
> + msg.msg_controllen = sizeof(u);
> }
> msg.msg_flags = MSG_WAITALL;
> ret = kernel_recvmsg(queue->sock, &msg, &iov, 1,
> @@ -1703,8 +1709,7 @@ static int nvme_tcp_recv_icresp(struct nvme_tcp_queue *queue,
> if (ret <= 0 || !nvme_tcp_queue_tls(queue))
> return ret;
>
> - ctype = tls_get_record_type(queue->sock->sk,
> - (struct cmsghdr *)cbuf);
> + ctype = tls_get_record_type(queue->sock->sk, &u.cmsg);
> if (ctype == TLS_RECORD_TYPE_DATA)
> return ret;
>
>
next prev parent reply other threads:[~2026-11-12 22:37 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-11 20:42 [PATCH v2 0/3] nvme-tcp: consume TLS records without application data on a live queue Martin Belanger via B4 Relay
2026-11-11 20:42 ` Martin Belanger
2026-11-11 20:42 ` [PATCH v2 1/3] nvme-tcp: use an aligned buffer for the TLS record type Martin Belanger via B4 Relay
2026-11-11 20:42 ` Martin Belanger
2026-11-12 12:23 ` Hannes Reinecke
2026-11-12 22:37 ` David Laight [this message]
2026-11-11 20:42 ` [PATCH v2 2/3] nvme-tcp: move the TLS record read loop into a helper Martin Belanger via B4 Relay
2026-11-11 20:42 ` Martin Belanger
2026-11-12 12:25 ` Hannes Reinecke
2026-11-11 20:42 ` [PATCH v2 3/3] nvme-tcp: consume TLS records without application data Martin Belanger via B4 Relay
2026-11-11 20:42 ` Martin Belanger
2026-11-11 22:54 ` sashiko-bot
2026-11-12 11:23 ` Martin Belanger
2026-11-12 12:32 ` Hannes Reinecke
2026-11-12 15:35 ` Martin Belanger
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=20261112223707.3bf1e1a6@pumpkin \
--to=david.laight.linux@gmail.com \
--cc=axboe@kernel.dk \
--cc=devnull+martin.nvme.dev.gmail.com@kernel.org \
--cc=hare@kernel.org \
--cc=hch@lst.de \
--cc=kbusch@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=martin.belanger@dell.com \
--cc=martin.nvme.dev@gmail.com \
--cc=sagi@grimberg.me \
--cc=stable@vger.kernel.org \
/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.