public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
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

  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