From: Sasha Levin <sashal@kernel.org>
To: linux-kernel@vger.kernel.org, stable@vger.kernel.org
Cc: Thinh Tran <thinhtr@linux.vnet.ibm.com>,
Venkata Sai Duggi <venkata.sai.duggi@ibm.com>,
David Christensen <drc@linux.vnet.ibm.com>,
Michael Chan <michael.chan@broadcom.com>,
Jakub Kicinski <kuba@kernel.org>, Sasha Levin <sashal@kernel.org>,
pavan.chebbi@broadcom.com, mchan@broadcom.com,
davem@davemloft.net, edumazet@google.com, pabeni@redhat.com,
netdev@vger.kernel.org
Subject: [PATCH AUTOSEL 5.10 11/16] net/tg3: fix race condition in tg3_reset_task()
Date: Mon, 11 Dec 2023 09:00:35 -0500 [thread overview]
Message-ID: <20231211140116.391986-11-sashal@kernel.org> (raw)
In-Reply-To: <20231211140116.391986-1-sashal@kernel.org>
From: Thinh Tran <thinhtr@linux.vnet.ibm.com>
[ Upstream commit 16b55b1f2269962fb6b5154b8bf43f37c9a96637 ]
When an EEH error is encountered by a PCI adapter, the EEH driver
modifies the PCI channel's state as shown below:
enum {
/* I/O channel is in normal state */
pci_channel_io_normal = (__force pci_channel_state_t) 1,
/* I/O to channel is blocked */
pci_channel_io_frozen = (__force pci_channel_state_t) 2,
/* PCI card is dead */
pci_channel_io_perm_failure = (__force pci_channel_state_t) 3,
};
If the same EEH error then causes the tg3 driver's transmit timeout
logic to execute, the tg3_tx_timeout() function schedules a reset
task via tg3_reset_task_schedule(), which may cause a race condition
between the tg3 and EEH driver as both attempt to recover the HW via
a reset action.
EEH driver gets error event
--> eeh_set_channel_state()
and set device to one of
error state above scheduler: tg3_reset_task() get
returned error from tg3_init_hw()
--> dev_close() shuts down the interface
tg3_io_slot_reset() and
tg3_io_resume() fail to
reset/resume the device
To resolve this issue, we avoid the race condition by checking the PCI
channel state in the tg3_reset_task() function and skip the tg3 driver
initiated reset when the PCI channel is not in the normal state. (The
driver has no access to tg3 device registers at this point and cannot
even complete the reset task successfully without external assistance.)
We'll leave the reset procedure to be managed by the EEH driver which
calls the tg3_io_error_detected(), tg3_io_slot_reset() and
tg3_io_resume() functions as appropriate.
Adding the same checking in tg3_dump_state() to avoid dumping all
device registers when the PCI channel is not in the normal state.
Signed-off-by: Thinh Tran <thinhtr@linux.vnet.ibm.com>
Tested-by: Venkata Sai Duggi <venkata.sai.duggi@ibm.com>
Reviewed-by: David Christensen <drc@linux.vnet.ibm.com>
Reviewed-by: Michael Chan <michael.chan@broadcom.com>
Link: https://lore.kernel.org/r/20231201001911.656-1-thinhtr@linux.vnet.ibm.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/broadcom/tg3.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/broadcom/tg3.c b/drivers/net/ethernet/broadcom/tg3.c
index 5647833303a44..57424d24681f9 100644
--- a/drivers/net/ethernet/broadcom/tg3.c
+++ b/drivers/net/ethernet/broadcom/tg3.c
@@ -6454,6 +6454,14 @@ static void tg3_dump_state(struct tg3 *tp)
int i;
u32 *regs;
+ /* If it is a PCI error, all registers will be 0xffff,
+ * we don't dump them out, just report the error and return
+ */
+ if (tp->pdev->error_state != pci_channel_io_normal) {
+ netdev_err(tp->dev, "PCI channel ERROR!\n");
+ return;
+ }
+
regs = kzalloc(TG3_REG_BLK_SIZE, GFP_ATOMIC);
if (!regs)
return;
@@ -11186,7 +11194,8 @@ static void tg3_reset_task(struct work_struct *work)
rtnl_lock();
tg3_full_lock(tp, 0);
- if (tp->pcierr_recovery || !netif_running(tp->dev)) {
+ if (tp->pcierr_recovery || !netif_running(tp->dev) ||
+ tp->pdev->error_state != pci_channel_io_normal) {
tg3_flag_clear(tp, RESET_TASK_PENDING);
tg3_full_unlock(tp);
rtnl_unlock();
--
2.42.0
next prev parent reply other threads:[~2023-12-11 14:01 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-11 14:00 [PATCH AUTOSEL 5.10 01/16] ASoC: wm8974: Correct boost mixer inputs Sasha Levin
2023-12-11 14:00 ` [PATCH AUTOSEL 5.10 02/16] ASoC: Intel: Skylake: Fix mem leak in few functions Sasha Levin
2023-12-11 14:00 ` [PATCH AUTOSEL 5.10 03/16] ASoC: nau8822: Fix incorrect type in assignment and cast to restricted __be16 Sasha Levin
2023-12-11 14:00 ` [PATCH AUTOSEL 5.10 04/16] ASoC: Intel: Skylake: mem leak in skl register function Sasha Levin
2023-12-11 14:00 ` [PATCH AUTOSEL 5.10 05/16] ASoC: cs43130: Fix the position of const qualifier Sasha Levin
2023-12-11 14:00 ` [PATCH AUTOSEL 5.10 06/16] ASoC: cs43130: Fix incorrect frame delay configuration Sasha Levin
2023-12-11 14:00 ` [PATCH AUTOSEL 5.10 07/16] ASoC: rt5650: add mutex to avoid the jack detection failure Sasha Levin
2023-12-11 14:00 ` [PATCH AUTOSEL 5.10 08/16] ASoC: Intel: skl_hda_dsp_generic: Drop HDMI routes when HDMI is not available Sasha Levin
2023-12-11 14:00 ` [PATCH AUTOSEL 5.10 09/16] nouveau/tu102: flush all pdbs on vmm flush Sasha Levin
2023-12-11 14:00 ` [PATCH AUTOSEL 5.10 10/16] ASoC: hdac_hda: Conditionally register dais for HDMI and Analog Sasha Levin
2023-12-11 14:00 ` Sasha Levin [this message]
2023-12-11 14:00 ` [PATCH AUTOSEL 5.10 12/16] ASoC: da7219: Support low DC impedance headset Sasha Levin
2023-12-11 14:00 ` [PATCH AUTOSEL 5.10 13/16] nvme: introduce helper function to get ctrl state Sasha Levin
2023-12-11 14:00 ` [PATCH AUTOSEL 5.10 14/16] mips/smp: Call rcutree_report_cpu_starting() earlier Sasha Levin
2023-12-11 14:00 ` [PATCH AUTOSEL 5.10 15/16] drm/exynos: fix a potential error pointer dereference Sasha Levin
2023-12-11 14:00 ` [PATCH AUTOSEL 5.10 16/16] drm/exynos: fix a wrong error checking Sasha Levin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20231211140116.391986-11-sashal@kernel.org \
--to=sashal@kernel.org \
--cc=davem@davemloft.net \
--cc=drc@linux.vnet.ibm.com \
--cc=edumazet@google.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mchan@broadcom.com \
--cc=michael.chan@broadcom.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=pavan.chebbi@broadcom.com \
--cc=stable@vger.kernel.org \
--cc=thinhtr@linux.vnet.ibm.com \
--cc=venkata.sai.duggi@ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox