Re: [PATCH net 02/15] ice: fix removal of PTP timestamp tracker during reset

On 9/15/2026 6:12 PM, Jakub Kicinski wrote:

[Severity: Medium]
Since peer PFs' trackers now survive CORER/GLOBR, can the clock owner's
rebuild flush race the peers?

ice_ptp_rebuild_owner() -> ice_ptp_flush_all_tx_tracker() walks every port of
the adapter:

		ice_ptp_flush_tx_tracker(ptp_port_to_pf(port), &port->tx);

and ice_ptp_flush_tx_tracker() does its PHY register work outside tx->lock:

	err = ice_get_phy_tx_tstamp_ready(hw, tx->block, &tstamp_ready);
	...
		if (!hw->reset_ongoing && (tstamp_ready & BIT_ULL(phy_idx)))
			ice_clear_phy_tstamp(hw, tx->block, phy_idx);

On E810/E830 each PF uses ICE_PTP_TX_INTERRUPT_SELF, so a peer PF that has
already finished its own ice_rebuild() (and therefore
ice_ptp_restore_timestamp_mode()) can be inside ice_ptp_process_tx_tstamp()
reading the same block:

	if (tx->has_ready_bitmap) {
		err = ice_get_phy_tx_tstamp_ready(hw, tx->block, &tstamp_ready);
	...
		err = ice_read_phy_tstamp(hw, tx->block, phy_idx, &raw_tstamp);

Before this patch the peers' trackers had been released (tx->len = 0, in_use
NULL, tx->init = 0), so the owner's flush iterated nothing and the peers could
not process.  Can a timestamp be cleared between the peer's ready-bitmap read
and its register read here, which the comment in ice_ptp_process_tx_tstamp()
warns can wedge the interrupt generation logic?  Note the teardown path
(ice_ptp_release_tx_tracker()) clears tx->init and calls synchronize_irq()
before flushing, but the rebuild flush has no equivalent quiesce for peer
PFs.

I am not 100% sure what we should do in this case. I think we either
need to make ICE_PTP_INTERRUPT_SELF handle flushings its own reset, or
we need to change something about how flushing works (maybe mark things
as stale instead and let the main thread handle erasure..)

For now, I have made a note of this and will address the feedback in a
followup after I can consider the behavior with the full series applied.