From: Martin Belanger <martin.nvme.dev@gmail.com>
To: David Laight <david.laight.linux@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 06:34:06 -0500 [thread overview]
Message-ID: <bc96a186-5a19-4896-8465-ccd1df5a33bf@gmail.com> (raw)
In-Reply-To: <20261112223707.3bf1e1a6@pumpkin>
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.
This is the form that cmsg(3) documents, and the kernel already uses
it:
- net/sunrpc/svcsock.c, svc_tcp_recv_cmsg(), and
net/sunrpc/xprtsock.c, xs_sock_recv_cmsg(): the same union, for
the same TLS record type
- arch/um/os-Linux/file.c, arch/um/os-Linux/skas/process.c and
arch/um/kernel/skas/stub.c: the same union for SCM_RIGHTS
The commit message of 1/3 names xs_tls_read_record(). The function
is xs_sock_recv_cmsg(). I will fix it in the next version, if there
is one.
> Did you test it?
> Or even compile it and compare the two object files.
Yes. I tested v2 and v3 with TLS records that carry no application
data, before the ICResp and on a live queue. These records go through
this buffer.
I also compared tcp.o before and after 1/3 (x86_64, gcc 15.2). Before,
cbuf is at %rsp+0x77 in nvme_tcp_recv_icresp() and at %rsp+0x7f in
nvme_tcp_skip_tls_record(). The stack pointer is only 8-byte aligned,
so the struct cmsghdr is not aligned, and put_cmsg() writes cmsg_len
to an unaligned address. After, the buffer is at %rsp+0x80 and the
stack is aligned to 16 bytes. msg_controllen changes from 17 to 24.
The other differences are register allocation and stack layout.
v3 has the same change in 1/3.
Martin
next prev parent reply other threads:[~2026-11-13 11:34 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 [this message]
2026-11-13 11:58 ` David Laight
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=bc96a186-5a19-4896-8465-ccd1df5a33bf@gmail.com \
--to=martin.nvme.dev@gmail.com \
--cc=axboe@kernel.dk \
--cc=david.laight.linux@gmail.com \
--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=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.