public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
From: Allison Henderson <allison.henderson@oracle.com>
To: "horms@kernel.org" <horms@kernel.org>,
	"achender@kernel.org" <achender@kernel.org>
Cc: "linux-rdma@vger.kernel.org" <linux-rdma@vger.kernel.org>,
	"rds-devel@oss.oracle.com" <rds-devel@oss.oracle.com>,
	"edumazet@google.com" <edumazet@google.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"linux-kselftest@vger.kernel.org"
	<linux-kselftest@vger.kernel.org>,
	"pabeni@redhat.com" <pabeni@redhat.com>,
	"kuba@kernel.org" <kuba@kernel.org>
Subject: Re: [net-next,v1,1/7] net/rds: new extension header: rdma bytes
Date: Tue, 27 Jan 2026 06:16:57 +0000	[thread overview]
Message-ID: <34fa8edd2fffdb76cab7a3c64d9694eaa717a97f.camel@oracle.com> (raw)
In-Reply-To: <20260126174620.1393182-1-horms@kernel.org>

On Mon, 2026-01-26 at 17:46 +0000, Simon Horman wrote:
> 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://urldefense.com/v3/__https://netdev-ai.bots.linux.dev/ai-local.html__;!!ACWV5N9M2RV99hQ!MPuQd8UZOu7Nec0FmSJuOO_TptptoR__bJuwS83q30PC3MeyF4iUF4CGt46bvEfQomEudN-E9bVMtVO05tU$ 
> 
> 
Ok I've got the reproducer working, I'll post an update when I get it resolved.

Thanks for the reviews!
Allison

> ---
> 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.
> 
> [ ... ]


  reply	other threads:[~2026-01-27  6:17 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   ` [net-next,v1,1/7] " Simon Horman
2026-01-27  6:16     ` Allison Henderson [this message]
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=34fa8edd2fffdb76cab7a3c64d9694eaa717a97f.camel@oracle.com \
    --to=allison.henderson@oracle.com \
    --cc=achender@kernel.org \
    --cc=edumazet@google.com \
    --cc=horms@kernel.org \
    --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