* [PATCH] tg3: Check return value of tg3_nvram_lock before resetting lock
@ 2025-02-11 15:26 Wentao Liang
2025-02-11 19:33 ` Joe Damato
2025-02-11 21:50 ` Michael Chan
0 siblings, 2 replies; 3+ messages in thread
From: Wentao Liang @ 2025-02-11 15:26 UTC (permalink / raw)
To: pavan.chebbi, mchan, andrew+netdev, davem, edumazet, kuba, pabeni
Cc: netdev, linux-kernel, Wentao Liang
The current code does not check the return value of tg3_nvram_lock before
resetting the lock count (tp->nvram_lock_cnt = 0). This is dangerous
because if tg3_nvram_lock fails, the lock state may be inconsistent,
leading to potential race conditions or undefined behavior.
This patch adds a check for the return value of tg3_nvram_lock. If the
function fails, the error is propagated to the caller, ensuring that
the lock state remains consistent.
Signed-off-by: Wentao Liang <vulab@iscas.ac.cn>
---
drivers/net/ethernet/broadcom/tg3.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/broadcom/tg3.c b/drivers/net/ethernet/broadcom/tg3.c
index 9cc8db10a8d6..851d19b3f43c 100644
--- a/drivers/net/ethernet/broadcom/tg3.c
+++ b/drivers/net/ethernet/broadcom/tg3.c
@@ -9160,7 +9160,9 @@ static int tg3_chip_reset(struct tg3 *tp)
if (!pci_device_is_present(tp->pdev))
return -ENODEV;
- tg3_nvram_lock(tp);
+ err = tg3_nvram_lock(tp);
+ if (err)
+ return err;
tg3_ape_lock(tp, TG3_APE_LOCK_GRC);
--
2.42.0.windows.2
^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: [PATCH] tg3: Check return value of tg3_nvram_lock before resetting lock
2025-02-11 15:26 [PATCH] tg3: Check return value of tg3_nvram_lock before resetting lock Wentao Liang
@ 2025-02-11 19:33 ` Joe Damato
2025-02-11 21:50 ` Michael Chan
1 sibling, 0 replies; 3+ messages in thread
From: Joe Damato @ 2025-02-11 19:33 UTC (permalink / raw)
To: Wentao Liang
Cc: pavan.chebbi, mchan, andrew+netdev, davem, edumazet, kuba, pabeni,
netdev, linux-kernel
On Tue, Feb 11, 2025 at 11:26:58PM +0800, Wentao Liang wrote:
> The current code does not check the return value of tg3_nvram_lock before
> resetting the lock count (tp->nvram_lock_cnt = 0). This is dangerous
> because if tg3_nvram_lock fails, the lock state may be inconsistent,
> leading to potential race conditions or undefined behavior.
>
> This patch adds a check for the return value of tg3_nvram_lock. If the
> function fails, the error is propagated to the caller, ensuring that
> the lock state remains consistent.
>
> Signed-off-by: Wentao Liang <vulab@iscas.ac.cn>
> ---
> drivers/net/ethernet/broadcom/tg3.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/broadcom/tg3.c b/drivers/net/ethernet/broadcom/tg3.c
> index 9cc8db10a8d6..851d19b3f43c 100644
> --- a/drivers/net/ethernet/broadcom/tg3.c
> +++ b/drivers/net/ethernet/broadcom/tg3.c
> @@ -9160,7 +9160,9 @@ static int tg3_chip_reset(struct tg3 *tp)
> if (!pci_device_is_present(tp->pdev))
> return -ENODEV;
>
> - tg3_nvram_lock(tp);
> + err = tg3_nvram_lock(tp);
> + if (err)
> + return err;
>
> tg3_ape_lock(tp, TG3_APE_LOCK_GRC);
A couple notes from me:
1. Subject should say "PATCH net-next"
2. Use --base=auto to generate a base-commit.
3. code looks fine to me, tg3_nvram_lock is checked in all other
invocations.
4. that said, seems like tg3_ape_lock could have also gotten a
check added at the same time?
I can see the argument that tg3_ape_lock cleanup should come
separately, since there are a few unchecked invocations of it other
than the one right next to the one you changed.
So, if you resend with 1 & 2 fixed, feel free to add:
Reviewed-by: Joe Damato <jdamato@fastly.com>
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] tg3: Check return value of tg3_nvram_lock before resetting lock
2025-02-11 15:26 [PATCH] tg3: Check return value of tg3_nvram_lock before resetting lock Wentao Liang
2025-02-11 19:33 ` Joe Damato
@ 2025-02-11 21:50 ` Michael Chan
1 sibling, 0 replies; 3+ messages in thread
From: Michael Chan @ 2025-02-11 21:50 UTC (permalink / raw)
To: Wentao Liang
Cc: pavan.chebbi, mchan, andrew+netdev, davem, edumazet, kuba, pabeni,
netdev, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 1557 bytes --]
On Tue, Feb 11, 2025 at 7:27 AM Wentao Liang <vulab@iscas.ac.cn> wrote:
>
> The current code does not check the return value of tg3_nvram_lock before
> resetting the lock count (tp->nvram_lock_cnt = 0). This is dangerous
> because if tg3_nvram_lock fails, the lock state may be inconsistent,
> leading to potential race conditions or undefined behavior.
>
> This patch adds a check for the return value of tg3_nvram_lock. If the
> function fails, the error is propagated to the caller, ensuring that
> the lock state remains consistent.
>
> Signed-off-by: Wentao Liang <vulab@iscas.ac.cn>
> ---
> drivers/net/ethernet/broadcom/tg3.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/broadcom/tg3.c b/drivers/net/ethernet/broadcom/tg3.c
> index 9cc8db10a8d6..851d19b3f43c 100644
> --- a/drivers/net/ethernet/broadcom/tg3.c
> +++ b/drivers/net/ethernet/broadcom/tg3.c
> @@ -9160,7 +9160,9 @@ static int tg3_chip_reset(struct tg3 *tp)
> if (!pci_device_is_present(tp->pdev))
> return -ENODEV;
>
> - tg3_nvram_lock(tp);
> + err = tg3_nvram_lock(tp);
> + if (err)
> + return err;
It is correct not to check the return value here since we are about to
reset the chip. The nvram lock is a hardware arbitration lock that is
granted by the hardware. If the hardware is in a bad state, we may
not get the lock but we should still proceed to reset. A few lines
below this we reset the tp->nvram_lock_cnt to 0 so it is safe.
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4209 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2025-02-11 21:50 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-02-11 15:26 [PATCH] tg3: Check return value of tg3_nvram_lock before resetting lock Wentao Liang
2025-02-11 19:33 ` Joe Damato
2025-02-11 21:50 ` Michael Chan
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox