| Message ID | 20231002185510.1488-1-thinhtr@linux.vnet.ibm.com (mailing list archive) |
|---|---|
| State | Changes Requested |
| Delegated to: | Netdev Maintainers |
| Headers | show |
| Series | net/tg3: fix race condition in tg3_reset_task_cancel() | expand |
On Tue, Oct 3, 2023 at 12:25 AM Thinh Tran <thinhtr@linux.vnet.ibm.com> wrote: > > during the EEH error injection tests on the 4-port 1 GbE NetXtreme > BCM5719 Gigabit Ethernet PCIe adapter, a race condition was observed in > the process of resetting and setting the driver flag to > TX_RECOVERY_PENDING between tg3_reset_task_cancel() and tg3_tx_recover(). > As a result, it occasionally leads to transmit timeouts and the > subsequent disabling of all the driver's interfaces. Can you elaborate on the race condition please? Are you saying tg3_reset_task_cancel() cleared the flag and tg3_tx_recover() set it again and the reset task never got a chance to run? Is that what is leading to TX stall?
On Mon, Oct 2, 2023 at 11:55 AM Thinh Tran <thinhtr@linux.vnet.ibm.com> wrote: > > during the EEH error injection tests on the 4-port 1 GbE NetXtreme > BCM5719 Gigabit Ethernet PCIe adapter, a race condition was observed in > the process of resetting and setting the driver flag to > TX_RECOVERY_PENDING between tg3_reset_task_cancel() and tg3_tx_recover(). > As a result, it occasionally leads to transmit timeouts and the > subsequent disabling of all the driver's interfaces. > > [12046.886221] NETDEV WATCHDOG: eth16 (tg3): transmit queue 0 timed out > [12046.886238] WARNING: CPU: 7 PID: 0 at ../net/sched/sch_generic.c:478 > dev_watchdog+0x42c/0x440 > [12046.886247] Modules linked in: tg3 libphy nfsv3 nfs_acl ....... > .......... > [12046.886571] tg3 0021:01:00.0 eth16: transmit timed out, resetting > ........... > [12046.966175] tg3 0021:01:00.1 eth15: transmit timed out, resetting > ........... > [12046.981584] tg3 0021:01:00.2 eth14: transmit timed out, resetting > ........... > [12047.056165] tg3 0021:01:00.3 eth13: transmit timed out, resetting > > > Fixing this issue by taking the spinlock when modifying the driver flag > > > Fixes: 6c4ca03bd890 ("net/tg3: resolve deadlock in tg3_reset_task() during EEH") > > > Signed-off-by: Thinh Tran <thinhtr@linux.vnet.ibm.com> > Tested-by: Venkata Sai Duggi <venkata.sai.duggi@ibm.com> > > --- > drivers/net/ethernet/broadcom/tg3.c | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/drivers/net/ethernet/broadcom/tg3.c b/drivers/net/ethernet/broadcom/tg3.c > index 14b311196b8f..f4558762f9de 100644 > --- a/drivers/net/ethernet/broadcom/tg3.c > +++ b/drivers/net/ethernet/broadcom/tg3.c > @@ -6507,7 +6507,9 @@ static void tg3_tx_recover(struct tg3 *tp) > "Please report the problem to the driver maintainer " > "and include system chipset information.\n"); > > + tg3_full_lock(tp, 0); > tg3_flag_set(tp, TX_RECOVERY_PENDING); > + tg3_full_unlock(tp); tg3_flag_set() calls set_bit() which is atomic. The same is true for tg3_flag_clear(). Maybe we just need some smp_mb__after_atomic() or similar memory barriers. > } > > static inline u32 tg3_tx_avail(struct tg3_napi *tnapi) > @@ -7210,7 +7212,10 @@ static inline void tg3_reset_task_cancel(struct tg3 *tp) > { > if (test_and_clear_bit(TG3_FLAG_RESET_TASK_PENDING, tp->tg3_flags)) > cancel_work_sync(&tp->reset_task); > + > + tg3_full_lock(tp, 0); > tg3_flag_clear(tp, TX_RECOVERY_PENDING); > + tg3_full_unlock(tp); > } > > static int tg3_poll_msix(struct napi_struct *napi, int budget) > -- > 2.25.1 >
Thanks for the review. On 10/3/2023 4:37 AM, Michael Chan wrote: > > tg3_flag_set() calls set_bit() which is atomic. The same is true for > tg3_flag_clear(). Maybe we just need some smp_mb__after_atomic() or > similar memory barriers. > I did not see it being used in this driver. I'll try that. Thinh Tran
Thanks for the review and I apologize for the delayed response. I had some trouble accessing the system, which delayed my investigation. On 10/2/2023 11:34 PM, Pavan Chebbi wrote: > > Can you elaborate on the race condition please? Are you saying > tg3_reset_task_cancel() cleared the flag and tg3_tx_recover() set it > again and the reset task never got a chance to run? > Is that what is leading to TX stall? This code path only triggered once, and after updating both the system and adapter firmware, I haven't encountered it again. However, the race condition issue still persists, causing the interfaces to go down. Implementing the memory barrier, smp_mb__after_atomic(), as suggested by Michael Chan, the intermittent problem still persists. Upon closer investigation, I identified the root cause, details in the next version of the patch. When I commented out the call to the tg3_dump_state() function in the tg3_tx_timeout() function, the issue occurred quicker. I'm working on submitting the v2 of the patch. Regards, Thinh Tran
Hi Michael, On 10/3/2023 5:05 PM, Thinh Tran wrote: > Thanks for the review. > > On 10/3/2023 4:37 AM, Michael Chan wrote: > >> >> tg3_flag_set() calls set_bit() which is atomic. The same is true for >> tg3_flag_clear(). Maybe we just need some smp_mb__after_atomic() or >> similar memory barriers. >> > > I did not see it being used in this driver. I'll try that. > > Thinh Tran > I tried that but still the intermittent problem still persists. I have a fix that I'll describe in V2 of the patch Thinh Tran
diff --git a/drivers/net/ethernet/broadcom/tg3.c b/drivers/net/ethernet/broadcom/tg3.c index 14b311196b8f..f4558762f9de 100644 --- a/drivers/net/ethernet/broadcom/tg3.c +++ b/drivers/net/ethernet/broadcom/tg3.c @@ -6507,7 +6507,9 @@ static void tg3_tx_recover(struct tg3 *tp) "Please report the problem to the driver maintainer " "and include system chipset information.\n"); + tg3_full_lock(tp, 0); tg3_flag_set(tp, TX_RECOVERY_PENDING); + tg3_full_unlock(tp); } static inline u32 tg3_tx_avail(struct tg3_napi *tnapi) @@ -7210,7 +7212,10 @@ static inline void tg3_reset_task_cancel(struct tg3 *tp) { if (test_and_clear_bit(TG3_FLAG_RESET_TASK_PENDING, tp->tg3_flags)) cancel_work_sync(&tp->reset_task); + + tg3_full_lock(tp, 0); tg3_flag_clear(tp, TX_RECOVERY_PENDING); + tg3_full_unlock(tp); } static int tg3_poll_msix(struct napi_struct *napi, int budget)
during the EEH error injection tests on the 4-port 1 GbE NetXtreme BCM5719 Gigabit Ethernet PCIe adapter, a race condition was observed in the process of resetting and setting the driver flag to TX_RECOVERY_PENDING between tg3_reset_task_cancel() and tg3_tx_recover(). As a result, it occasionally leads to transmit timeouts and the subsequent disabling of all the driver's interfaces. [12046.886221] NETDEV WATCHDOG: eth16 (tg3): transmit queue 0 timed out [12046.886238] WARNING: CPU: 7 PID: 0 at ../net/sched/sch_generic.c:478 dev_watchdog+0x42c/0x440 [12046.886247] Modules linked in: tg3 libphy nfsv3 nfs_acl ....... .......... [12046.886571] tg3 0021:01:00.0 eth16: transmit timed out, resetting ........... [12046.966175] tg3 0021:01:00.1 eth15: transmit timed out, resetting ........... [12046.981584] tg3 0021:01:00.2 eth14: transmit timed out, resetting ........... [12047.056165] tg3 0021:01:00.3 eth13: transmit timed out, resetting Fixing this issue by taking the spinlock when modifying the driver flag Fixes: 6c4ca03bd890 ("net/tg3: resolve deadlock in tg3_reset_task() during EEH") Signed-off-by: Thinh Tran <thinhtr@linux.vnet.ibm.com> Tested-by: Venkata Sai Duggi <venkata.sai.duggi@ibm.com> --- drivers/net/ethernet/broadcom/tg3.c | 5 +++++ 1 file changed, 5 insertions(+)