On 8/21/2026 5:13 PM, Jacob Keller wrote:
> diff --git a/drivers/net/ethernet/intel/ice/ice_ptp.c
> b/drivers/net/ethernet/intel/ice/ice_ptp.c
> index a049dc7a2241..1a9bf8839404 100644
> --- a/drivers/net/ethernet/intel/ice/ice_ptp.c
> +++ b/drivers/net/ethernet/intel/ice/ice_ptp.c
> @@ -581,14 +583,11 @@ static void ice_ptp_process_tx_tstamp(struct ice_ptp_tx
> *tx)
> return;
> }
>
> - /* Drop packets if the link went down */
> - link_up = ptp_port->link_up;
> -
> for_each_set_bit(idx, tx->in_use, tx->len) {
> struct skb_shared_hwtstamps shhwtstamps = {};
> u8 phy_idx = idx + tx->offset;
> u64 raw_tstamp = 0, tstamp;
> - bool drop_ts = !link_up;
> + bool drop_ts = false;
> struct sk_buff *skb;
>
Sashiko says:
> This is a pre-existing issue, but does the lockless traversal of
> tx->in_use here race with new timestamp allocations?
> In drivers/net/ethernet/intel/ice/ice_ptp.c:ice_ptp_request_ts(), the in_use
> bit is set before the timestamp start and skb fields are initialized:
> set_bit(idx, tx->in_use);
> clear_bit(idx, tx->stale);
> tx->tstamps[idx].start = jiffies;
> tx->tstamps[idx].skb = skb_get(skb);
> If this processing loop runs concurrently in an IRQ or worker thread, could
> it see the newly set in_use bit but read a stale start value from a prior
> use of the index?
> If that stale time happens to be older than the 2-second timeout, the loop
> will set drop_ts = true, acquire tx->lock, and clear in_use. Depending on
> whether the new skb pointer is visible yet, couldn't this cause the new Tx
> request to be incorrectly dropped, or its skb to be permanently leaked?
I think this was pointed out by a previous change as well. I'll include
a proper fix for this in the series in v2.
Thanks,
Jake
