Re: [PATCH net v2] pds_core: keep the health thread stopped during reset

[Jakub Kicinski <kuba@kernel.org>]

This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
---
--- Patch [1]: [PATCH net v2] pds_core: keep the health thread stopped during reset ---
commit 253bc338bd6e7dd7e1be6b7664ab1b26f176624e
Author: Nikhil P. Rao <nikhil.rao@amd.com>

pds_core: keep the health thread stopped during reset

This commit replaces cancel_work_sync() with disable_work_sync() for the
health thread to ensure it doesn't get re-queued by a timeout during reset.
It then restarts the thread using enable_work().

Link: https://sashiko.dev/#/patchset/20260629200358.2626129-1-nikhil.rao%40amd.com?part=2

> diff --git a/drivers/net/ethernet/amd/pds_core/main.c b/drivers/net/ethernet/amd/pds_core/main.c
> index 8d94a4d70395e..ccb8aa7b95f7e 100644
> --- a/drivers/net/ethernet/amd/pds_core/main.c
> +++ b/drivers/net/ethernet/amd/pds_core/main.c
> @@ -471,7 +471,7 @@ static void pdsc_stop_health_thread(struct pdsc *pdsc)
>  
>  	timer_shutdown_sync(&pdsc->wdtimer);
>  	if (pdsc->health_work.func)
> -		cancel_work_sync(&pdsc->health_work);
> +		disable_work_sync(&pdsc->health_work);

[Severity: High]
Could this lead to an unbalanced disable count during an Advanced Error
Reporting (AER) reset?

Unlike cancel_work_sync(), disable_work_sync() increments a depth counter.
During an AER fatal error, pdsc_pci_error_detected() manually invokes
pdsc_reset_prepare(), which calls pdsc_stop_health_thread(), setting the
disable count to 1.

Later, the AER resume path in pdsc_pci_error_resume() calls
pci_reset_function_locked(), which internally calls the driver's
.reset_prepare callback a second time:

drivers/pci/pci.c:pci_reset_function_locked() {
	pci_dev_save_and_disable(dev);
	rc = __pci_reset_function_locked(dev);
	pci_dev_restore(dev);
}

Because pci_dev_save_and_disable() invokes the driver's .reset_prepare,
the disable count increments to 2. However, pci_dev_restore() only triggers
.reset_done once, which means enable_work() is only called once.

Will this leave the health work item permanently disabled (with a count of 1),
preventing the driver from monitoring firmware health or triggering future
recoveries?
-- 
pw-bot: cr