netdev - Re: [PATCH] net/tg3: fix race condition in tg3_reset_task

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Tue, 3 Oct 2023 02:37:37 -0700
From: Michael Chan <michael.chan@...adcom.com>
To: Thinh Tran <thinhtr@...ux.vnet.ibm.com>
Cc: netdev@...r.kernel.org, siva.kallam@...adcom.com, prashant@...adcom.com, 
	mchan@...adcom.com, drc@...ux.vnet.ibm.com, pavan.chebbi@...adcom.com, 
	Venkata Sai Duggi <venkata.sai.duggi@....com>
Subject: Re: [PATCH] net/tg3: fix race condition in tg3_reset_task_cancel()

On Mon, Oct 2, 2023 at 11:55 AM Thinh Tran <thinhtr@...ux.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@...ux.vnet.ibm.com>
> Tested-by: Venkata Sai Duggi <venkata.sai.duggi@....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
>

Download attachment "smime.p7s" of type "application/pkcs7-signature" (4209 bytes)