> -----Original Message----- > From: Intel-wired-lan <[email protected]> On Behalf Of Paul > Greenwalt > Sent: 26 May 2026 21:18 > To: [email protected] > Cc: Greenwalt, Paul <[email protected]>; Kitszel, Przemyslaw > <[email protected]>; Loktionov, Aleksandr > <[email protected]> > Subject: [Intel-wired-lan] [PATCH iwl-net v1] ice: prevent tstamp ring > allocation for non-PF VSI types > > The pf->txtime_txqs bitmap tracks which Tx queues have ETF (Earliest TxTime > First) offload enabled. This bitmap is indexed by queue number and is set by > ice_offload_txtime(), which only operates on PF VSI queues. > > However, ice_is_txtime_ena() does not check the VSI type before consulting > the bitmap. When ETF offload is enabled on PF Tx queue 0, bit 0 is set in > pf->txtime_txqs. During a subsequent PCI reset rebuild, the CTRL VSI's Tx > queue 0 is reconfigured and > ice_is_txtime_ena() is called for that ring. Since it only checks > pf->txtime_txqs by queue index without distinguishing VSI type, it > finds bit 0 set and returns true, matching the PF VSI's ETF queue, not the > CTRL VSI's. This causes ice_vsi_cfg_txq() to spuriously allocate a > tstamp_ring for the CTRL VSI ring. > > Since CTRL VSI rings have no associated netdev, ice_clean_tx_ring() takes an > early return at the !netdev check before reaching ice_free_tx_tstamp_ring(), > leaking the allocation. Each PCI reset leaks one 64-byte tstamp_ring. > > Fix this by restricting ice_is_txtime_ena() to return true only for PF VSI > rings, since txtime_txqs is only meaningful for PF VSI queues. > > Fixes: ccde82e90946 ("ice: add E830 Earliest TxTime First Offload support") > Signed-off-by: Paul Greenwalt <[email protected]> > Reviewed-by: Przemek Kitszel <[email protected]> > Reviewed-by: Aleksandr Loktionov <[email protected]> > --- > drivers/net/ethernet/intel/ice/ice.h | 3 +++ > 1 file changed, 3 insertions(+) >
Tested-by: Rinitha S <[email protected]> (A Contingent worker at Intel)
