From: Simon Horman <horms@kernel.org>
To: achender@kernel.org
Cc: Simon Horman <horms@kernel.org>,
pabeni@redhat.com, rds-devel@oss.oracle.com,
netdev@vger.kernel.org, allison.henderson@oracle.com,
edumazet@google.com, linux-kselftest@vger.kernel.org,
kuba@kernel.org, linux-rdma@vger.kernel.org
Subject: Re: [net-next,v1,1/7] net/rds: new extension header: rdma bytes
Date: Mon, 26 Jan 2026 17:46:20 +0000 [thread overview]
Message-ID: <20260126174620.1393182-1-horms@kernel.org> (raw)
In-Reply-To: <20260125070651.207042-2-achender@kernel.org>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
For local reproduction steps see https://netdev-ai.bots.linux.dev/ai-local.html
---
net/rds: new extension header: rdma bytes
This patch introduces a new extension header type RDS_EXTHDR_RDMA_BYTES
to allow RDMA initiators to exchange byte counts with their targets for
statistics and policy purposes. It also expands rds_message_add_extension()
to support multiple extensions per message.
> diff --git a/net/rds/rds.h b/net/rds/rds.h
> index 8a549fe687ac..cadfd7ec0ba9 100644
> --- a/net/rds/rds.h
> +++ b/net/rds/rds.h
[ ... ]
> @@ -258,6 +259,19 @@ struct rds_ext_header_rdma_dest {
> __be32 h_rdma_offset;
> };
>
> +/*
> + * This extension header tells the peer about delivered RDMA byte count.
> + */
> +#define RDS_EXTHDR_RDMA_BYTES 4
> +
> +struct rds_ext_header_rdma_bytes {
> + __be32 h_rdma_bytes; /* byte count */
> + u8 h_rflags; /* direction of RDMA, write or read */
> +};
This struct has 5 bytes of actual data but sizeof() will return 8 bytes
due to alignment padding. The 3 padding bytes after h_rflags are not
initialized when this struct is used in rds_ib_xmit(). Since
rds_message_add_extension() copies sizeof(struct) bytes via memcpy(),
those uninitialized padding bytes get transmitted to the peer.
Should this struct be marked __packed, or should the declaration in
rds_ib_xmit() use a zeroing initializer like = {} to avoid leaking
kernel stack contents over the network?
> diff --git a/net/rds/ib_send.c b/net/rds/ib_send.c
> index f9d28ddd168d..8282ff61b0b3 100644
> --- a/net/rds/ib_send.c
> +++ b/net/rds/ib_send.c
> @@ -578,10 +578,27 @@ int rds_ib_xmit(struct rds_connection *conn, struct rds_message *rm,
> * used by the peer to release use-once RDMA MRs. */
> if (rm->rdma.op_active) {
> struct rds_ext_header_rdma ext_hdr;
> + struct rds_ext_header_rdma_bytes rdma_bytes_ext_hdr;
>
> ext_hdr.h_rdma_rkey = cpu_to_be32(rm->rdma.op_rkey);
> rds_message_add_extension(&rm->m_inc.i_hdr,
> - RDS_EXTHDR_RDMA, &ext_hdr, sizeof(ext_hdr));
> + RDS_EXTHDR_RDMA, &ext_hdr);
> +
> + /* prepare the rdma bytes ext header */
> + rdma_bytes_ext_hdr.h_rflags = rm->rdma.op_write ?
> + RDS_FLAG_RDMA_WR_BYTES : RDS_FLAG_RDMA_RD_BYTES;
> + rdma_bytes_ext_hdr.h_rdma_bytes =
> + cpu_to_be32(rm->rdma.op_bytes);
Here rdma_bytes_ext_hdr is declared on the stack without initialization.
Only h_rflags and h_rdma_bytes are assigned, leaving the 3 padding bytes
uninitialized. When rds_message_add_extension() calls memcpy() with
len = sizeof(struct rds_ext_header_rdma_bytes) = 8, those uninitialized
bytes are copied into the header and sent to the peer.
[ ... ]
--
pw-bot: cr
next prev parent reply other threads:[~2026-01-26 17:46 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-25 7:06 [PATCH net-next v1 0/7] net/rds: RDS-TCP protocol and extension improvements Allison Henderson
2026-01-25 7:06 ` [PATCH net-next v1 1/7] net/rds: new extension header: rdma bytes Allison Henderson
2026-01-26 17:46 ` Simon Horman [this message]
2026-01-27 6:16 ` [net-next,v1,1/7] " Allison Henderson
2026-01-25 7:06 ` [PATCH net-next v1 2/7] net/rds: Encode cp_index in TCP source port Allison Henderson
2026-01-25 7:06 ` [PATCH net-next v1 3/7] net/rds: rds_tcp_conn_path_shutdown must not discard messages Allison Henderson
2026-01-25 7:06 ` [PATCH net-next v1 4/7] net/rds: Kick-start TCP receiver after accept Allison Henderson
2026-01-25 7:06 ` [PATCH net-next v1 5/7] net/rds: Clear reconnect pending bit Allison Henderson
2026-01-25 7:06 ` [PATCH net-next v1 6/7] net/rds: Use the first lane until RDS_EXTHDR_NPATHS arrives Allison Henderson
2026-01-25 7:06 ` [PATCH net-next v1 7/7] net/rds: Trigger rds_send_ping() more than once Allison Henderson
2026-01-26 17:47 ` [net-next,v1,7/7] " Simon Horman
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=20260126174620.1393182-1-horms@kernel.org \
--to=horms@kernel.org \
--cc=achender@kernel.org \
--cc=allison.henderson@oracle.com \
--cc=edumazet@google.com \
--cc=kuba@kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=rds-devel@oss.oracle.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox