[PATCH net-next] net/rds: clear i_rx_lat_trace in rds_inc_path_init()

[PATCH net-next] net/rds: clear i_rx_lat_trace in rds_inc_path_init()

[Allison Henderson]

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>
---
 net/rds/recv.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/net/rds/recv.c b/net/rds/recv.c
index f1513dfb2716..6204e577a90a 100644
--- a/net/rds/recv.c
+++ b/net/rds/recv.c
@@ -66,6 +66,8 @@ void rds_inc_path_init(struct rds_incoming *inc, struct rds_conn_path *cp,
 	inc->i_saddr = *saddr;
 	inc->i_usercopy.rdma_cookie = 0;
 	inc->i_usercopy.rx_tstamp = ktime_set(0, 0);
+
+	memset(inc->i_rx_lat_trace, 0, sizeof(inc->i_rx_lat_trace));
 }
 EXPORT_SYMBOL_GPL(rds_inc_path_init);
 

base-commit: 4fa4977a0d900f936bcae5cd2c510be5554e8dd6
prerequisite-patch-id: ac6fbdba01fa66022d37321e8270d4f9f9fb834b
prerequisite-patch-id: 45883e7cfa080a48b943e4ba58e0da22767c4c01
-- 
2.25.1

Re: [PATCH net-next] net/rds: clear i_rx_lat_trace in rds_inc_path_init()

[Simon Horman]

On Sun, Aug 09, 2026 at 10:56:31PM -0700, 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>

Reviewed-by: Simon Horman <horms@kernel.org>

Re: [PATCH net-next] net/rds: clear i_rx_lat_trace in rds_inc_path_init()

[Paolo Abeni]

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

Re: [PATCH net-next] net/rds: clear i_rx_lat_trace in rds_inc_path_init()

[patchwork-bot+netdevbpf]

Hello:

This patch was applied to netdev/net-next.git (main)
by Paolo Abeni <pabeni@redhat.com>:

On Sun,  9 Aug 2026 22:56:31 -0700 you 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.
> 
> [...]

Here is the summary with links:
  - [net-next] net/rds: clear i_rx_lat_trace in rds_inc_path_init()
    https://git.kernel.org/netdev/net-next/c/68b3d4dbaf20

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html

Re: [PATCH net-next] net/rds: clear i_rx_lat_trace in rds_inc_path_init()

[Allison Henderson]

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