Re: [PATCH 2/3] remoteproc: Prevent crash handling to race with rproc_del()

[Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>]

On 7/23/26 5:52 AM, Bjorn Andersson wrote:
> There's no synchronization between rproc_crash_handler_work() and
> rproc_del(), as such it's possible for a driver to be removed while
> crash-handler work is scheduled, or even executing - resulting in
> use-after-free issues.

[...]

> +	spin_lock_irqsave(&rproc->crash_handler_lock, flags);
> +	if (READ_ONCE(rproc->deleting)) {
> +		spin_unlock_irqrestore(&rproc->crash_handler_lock, flags);
> +		return;
> +	}
> +
>  	/* Prevent suspend while the remoteproc is being recovered */
>  	pm_stay_awake(rproc->dev.parent);
> +	queue_work(rproc_recovery_wq, &rproc->crash_handler);
> +	spin_unlock_irqrestore(&rproc->crash_handler_lock, flags);
>  
>  	dev_err(&rproc->dev, "crash detected in %s: type %s\n",
>  		rproc->name, rproc_crash_to_string(type));

GPT reported that the rproc may be gone/deleting at the time of
this print since it's outside the lock, so it's not a given that
rproc->dev and rproc->name are valid (although the window is pretty
slim..)

Konrad