From: David Laight <david.laight.linux@gmail.com>
To: Martin Belanger <martin.nvme.dev@gmail.com>
Cc: 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: Fri, 13 Nov 2026 11:58:24 +0000 [thread overview]
Message-ID: <20261113115824.2f96b66b@pumpkin> (raw)
In-Reply-To: <bc96a186-5a19-4896-8465-ccd1df5a33bf@gmail.com>
On Fri, 13 Nov 2026 06:34:06 -0500
Martin Belanger <martin.nvme.dev@gmail.com> wrote:
> On 11/12/26 17:37, David Laight wrote:
> > 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.
>
> I think the union is right. buf[] covers the whole control message:
> the header, the data and the padding. CMSG_SPACE(1) already includes
> sizeof(struct cmsghdr). The cmsghdr member only gives the buffer its
> alignment. With a struct, the header would be counted twice.
>
> On x86_64, CMSG_LEN(1) is 17 and CMSG_SPACE(1) is 24. The union is 24
> bytes with 8-byte alignment. put_cmsg() writes CMSG_LEN(1) bytes and
> sets cmsg_len to 17, as before. It then advances msg_control by
> min(CMSG_SPACE(1), msg_controllen), so CMSG_SPACE() is the size it
> expects.
Ok, you are changing the size - which is what I noticed.
In this case it makes the on-stack buffer 4 bytes bigger - which
probably doesn't matter.
I'm sort of surprised it is 8 byte aligned.
Historically it would have been 4 byte aligned, and the kernel still
has to handle requests from 32 bit apps where I'm pretty sure the buffer
will only be 4 byte aligned.
But I've not checked and it isn't really relevant here.
David
next prev parent reply other threads:[~2026-11-13 11:58 UTC|newest]
Thread overview: 17+ 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
2026-11-13 11:34 ` Martin Belanger
2026-11-13 11:58 ` 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=20261113115824.2f96b66b@pumpkin \
--to=david.laight.linux@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=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.