Re: [net-next 05/13] igc: Check __IGC_PTP_TX_IN_PROGRESS instead of ptp_tx_skb

[Andre Guedes <andre.guedes@intel.com>]

Quoting Jakub Kicinski (2020-06-29 15:11:17)
> On Mon, 29 Jun 2020 13:51:32 -0700 Andre Guedes wrote:
> > > > @@ -435,6 +432,9 @@ static void igc_ptp_tx_hwtstamp(struct igc_adapter *adapter)
> > > >       struct igc_hw *hw = &adapter->hw;
> > > >       u64 regval;
> > > >  
> > > > +     if (WARN_ON_ONCE(!skb))
> > > > +             return;
> > > > +
> > > >       regval = rd32(IGC_TXSTMPL);
> > > >       regval |= (u64)rd32(IGC_TXSTMPH) << 32;
> > > >       igc_ptp_systim_to_hwtstamp(adapter, &shhwtstamps, regval);
> > > > @@ -466,7 +466,7 @@ static void igc_ptp_tx_work(struct work_struct *work)
> > > >       struct igc_hw *hw = &adapter->hw;
> > > >       u32 tsynctxctl;
> > > >  
> > > > -     if (!adapter->ptp_tx_skb)
> > > > +     if (!test_bit(__IGC_PTP_TX_IN_PROGRESS, &adapter->state))
> > > >               return;  
> > > 
> > > Not that reading ptp_tx_skb is particularly correct here, but I think
> > > it's better. See how they get set:
> > > 
> > >                 if (adapter->tstamp_config.tx_type == HWTSTAMP_TX_ON &&
> > >                     !test_and_set_bit_lock(__IGC_PTP_TX_IN_PROGRESS,
> > >                                            &adapter->state)) {
> > >                         skb_shinfo(skb)->tx_flags |= SKBTX_IN_PROGRESS;
> > >                         tx_flags |= IGC_TX_FLAGS_TSTAMP;
> > > 
> > >                         adapter->ptp_tx_skb = skb_get(skb);
> > >                         adapter->ptp_tx_start = jiffies;
> > > 
> > > bit is set first and other fields after. Since there is no locking here
> > > we may just see the bit but none of the fields set.  
> > 
> > I see your point, but note that the code within the if-block and the code in
> > igc_ptp_tx_work() don't execute concurrently. adapter->ptp_tx_work is scheduled
> > only on a time-sync interrupt, which is triggered if IGC_TX_FLAGS_TSTAMP is
> > set (so adapter->ptp_tx_skb is valid).
> 
> What if timeout happens, igc_ptp_tx_hang() starts cleaning up and then
> irq gets delivered half way through? Perhaps we should just add a spin
> lock around the ptp_tx_s* fields?

Yep, I think this other scenario is possible indeed, and we should probably
protect ptp_tx_s* with a lock. Thanks for pointing that out. In fact, it seems
this issue can happen even with current net-next code.

Since that issue is not introduced by this patch, would it be OK we move forward
with it, and fix the issue in a separate patch?

- Andre