Files
linux/net/rds
Allison Henderson 68b3d4dbaf net/rds: clear i_rx_lat_trace in rds_inc_path_init()
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 1635bb548f
("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>
Link: https://patch.msgid.link/20260810055631.299558-1-achender@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-08-13 12:53:14 +02:00
..
2026-06-11 12:19:05 +02:00
2026-01-13 12:27:03 +01:00
2021-05-31 22:45:05 -07:00
2026-04-12 13:33:19 -07:00
2026-06-11 12:19:05 +02:00
2011-07-01 16:16:19 -07:00
2026-01-13 12:27:03 +01:00