Re: [PATCH iwl-net 09/12] ice: keep Tx timestamp slots tracked until completion or timeout

[Jacob Keller <jacob.e.keller@intel.com>]

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