From: Martin Belanger <martin.nvme.dev@gmail.com>
To: sashiko-reviews@lists.linux.dev
Cc: linux-nvme@lists.infradead.org, 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-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] nvme-tcp: move the TLS record read loop into a helper
Date: Mon, 9 Nov 2026 14:30:01 -0500 [thread overview]
Message-ID: <ee61d52b-e8bb-4504-a893-f9dc4036d615@gmail.com> (raw)
In-Reply-To: <sashiko-outbox-205465@kernel.org>
On 11/9/26 14:11, sashiko-bot@kernel.org wrote:
> [Severity: Medium]
> This problem wasn't introduced by this patch, but can passing the
unaligned
> char cbuf[] array as msg_control [1] cause unaligned struct cmsghdr
> accesses?
The report is correct. The char cbuf[CMSG_LEN(sizeof(char))] pattern
gives the buffer 1-byte alignment, and put_cmsg() and
tls_get_record_type() access it as a struct cmsghdr. The pattern exists
since commit 2837966ab2a8 ("nvme-tcp: control message handling for
recvmsg()"), and this series copies it into the two new receive paths.
v2 will add a first patch that declares the host buffers as a union
with struct cmsghdr, as sunrpc does in svcsock.c and xprtsock.c. The
new code in this series will use the same declaration. I will wait for
review of v1 before I post v2.
nvmet-tcp uses the same pattern in four places. I will fix it in a
separate patch.
Martin
next prev parent reply other threads:[~2026-11-09 19:30 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-09 19:04 [PATCH 0/2] nvme-tcp: consume TLS records without application data on a live queue Martin Belanger
2026-11-09 19:04 ` Martin Belanger via B4 Relay
2026-11-09 19:04 ` [PATCH 1/2] nvme-tcp: move the TLS record read loop into a helper Martin Belanger
2026-11-09 19:04 ` Martin Belanger via B4 Relay
2026-11-09 19:11 ` sashiko-bot
2026-11-09 19:30 ` Martin Belanger [this message]
2026-11-09 19:04 ` [PATCH 2/2] nvme-tcp: consume TLS records without application data Martin Belanger
2026-11-09 19:04 ` Martin Belanger via B4 Relay
2026-11-09 19:21 ` sashiko-bot
2026-11-09 19:36 ` 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=ee61d52b-e8bb-4504-a893-f9dc4036d615@gmail.com \
--to=martin.nvme.dev@gmail.com \
--cc=axboe@kernel.dk \
--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=sagi@grimberg.me \
--cc=sashiko-reviews@lists.linux.dev \
/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.