Linux RDMA and InfiniBand development
 help / color / mirror / Atom feed
From: Allison Henderson <achender@kernel.org>
To: Paolo Abeni <pabeni@redhat.com>,
	netdev@vger.kernel.org,  linux-rdma@vger.kernel.org,
	edumazet@google.com, kuba@kernel.org, horms@kernel.org
Cc: jhubbard@nvidia.com, leon@kernel.org
Subject: Re: [PATCH net-next] net/rds: clear i_rx_lat_trace in rds_inc_path_init()
Date: Thu, 13 Aug 2026 17:25:55 -0700	[thread overview]
Message-ID: <920ffe1984d3fe81ae3deb72129499444a99703f.camel@kernel.org> (raw)
In-Reply-To: <a227ef96-9b2a-4f8f-9fac-c725eeb0e998@redhat.com>

On Thu, 2026-08-13 at 12:50 +0200, Paolo Abeni wrote:
> On 8/10/26 7:56 AM, Allison Henderson wrote:
> > The commit that introduced the receive-path latency trace added the
> > clearing of inc->i_rx_lat_trace[] to rds_inc_init() only;
> > rds_inc_path_init() never got it.
> > 
> > That asymmetry matters for the one caller that reuses memory:
> > rds_tcp_data_recv() carves its rds_tcp_incoming out of a kmem_cache
> > with no zeroing and no constructor, so after rds_inc_path_init() the
> > array still holds the timestamps of whatever message previously
> > occupied that slab object.  No stale value is user-visible today -
> > every message that reaches the socket happens to overwrite all four
> > slots (RX_HDR at allocation, RX_START when the header completes,
> > RX_END at delivery, RX_CMSG at recvmsg time) before
> > RDS_CMSG_RXPATH_LATENCY reads them back as deltas - but that is a
> > property of the current writers, not of the init contract, and a
> > future trace point or an early-exit path would expose another
> > message's timestamps to userspace.
> > 
> > Clear the array in rds_inc_path_init() too, so both init helpers
> > leave the inc fully initialized.  memset is the form the clearing
> > already takes on the rds_inc_init() side since commit 1635bb548f84
> > ("net: rds: use memset to optimize the recv").  Hardening only; no
> > user-visible bug in the current code.
> > 
> > Assisted-by: Claude-Code:claude-fable-5
> > Signed-off-by: Allison Henderson <achender@kernel.org>
> Mentioning this change in the previous series thread would have saved me
> a lot of time :(
> 
> /P
> 
Sorry about that!  You're right, the follow-up came out of the same
review pass as v2, and I should have replied to the series thread with
a pointer to it.  I'll be sure to cross-reference follow-ups like that
in the future.

Thank you for picking up all three!

Allison




  reply	other threads:[~2026-08-14  0:25 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-10  5:56 [PATCH net-next] net/rds: clear i_rx_lat_trace in rds_inc_path_init() Allison Henderson
2026-08-11 10:54 ` Simon Horman
2026-08-13 10:50 ` Paolo Abeni
2026-08-14  0:25   ` Allison Henderson [this message]
2026-08-13 11:00 ` patchwork-bot+netdevbpf

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=920ffe1984d3fe81ae3deb72129499444a99703f.camel@kernel.org \
    --to=achender@kernel.org \
    --cc=edumazet@google.com \
    --cc=horms@kernel.org \
    --cc=jhubbard@nvidia.com \
    --cc=kuba@kernel.org \
    --cc=leon@kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.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