Re: [PATCH v1] hwmon: (pwm-fan) Stop RPM timer before freeing tach data

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Missing lock in pwm_fan_cleanup leads to data race and potential memory/HW state corruption during system shutdown.
--

commit 7dfed1a79b0f4d06cbff416478ab737ce3920c29
Author: Yibo Tan <lhfff@tju.edu.cn>

hwmon: (pwm-fan) Stop RPM timer before freeing tach data

This commit fixes a use-after-free bug where driver detach can free timer
backing arrays before the timer is shut down. It does this by splitting the
timer retirement from power cleanup and registering its devres action after
the timer backing data is installed.

> diff --git a/drivers/hwmon/pwm-fan.c b/drivers/hwmon/pwm-fan.c
> index 3b87f65bae058..c633d7f6464c7 100644
> --- a/drivers/hwmon/pwm-fan.c
> +++ b/drivers/hwmon/pwm-fan.c

[ ... ]

> @@ -700,6 +710,7 @@ static void pwm_fan_shutdown(struct platform_device *pdev)
>  {
>  	struct pwm_fan_ctx *ctx = platform_get_drvdata(pdev);
>  
> +	pwm_fan_timer_cleanup(ctx);
>  	pwm_fan_cleanup(ctx);

[Severity: High]
This is a pre-existing issue, but does this unlocked call to
pwm_fan_cleanup() create a data race with the thermal subsystem?

During system shutdown, pwm_fan_shutdown() invokes pwm_fan_cleanup()
without holding ctx->lock. At the same time, if the kernel's thermal
governor triggers a temperature update, it can follow this path:

pwm_fan_set_cur_state()
  set_pwm()
    __set_pwm()

The thermal path acquires ctx->lock, but because pwm_fan_cleanup() modifies
ctx->enable_mode and ctx->pwm_state locklessly, these operations can race.
Could this result in invalid configurations being passed to the PWM driver
during shutdown, potentially causing a crash or malfunction?

>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260911071809.130151-1-lhfff@tju.edu.cn?part=1