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 --- 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