Re: [PATCH v7 3/9] remoteproc: qcom: pas: add support for TMD thermal cooling devices

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] TOCTOU race in qmi_tmd_register and disconnected state desynchronization.
--

--- Patch [3]: [PATCH v7 3/9] remoteproc: qcom: pas: add support for TMD thermal cooling devices ---
commit 89eed46353741313ceea667539ac871767ff067e
Author: Gaurav Kohli <gaurav.kohli@oss.qualcomm.com>

remoteproc: qcom: pas: add support for TMD thermal cooling devices

This commit registers Thermal Mitigation Devices (TMDs) for PAS-managed
remote processors to enable thermal throttling through QMI. It allows the
thermal framework to request mitigation when remote subsystems such as modem
and CDSP contribute to thermal pressure.

> diff --git a/drivers/remoteproc/qcom_q6v5_pas.c b/drivers/remoteproc/qcom_q6v5_pas.c
> index 25599d7282083..b9c01ce5024ed 100644
> --- a/drivers/remoteproc/qcom_q6v5_pas.c
> +++ b/drivers/remoteproc/qcom_q6v5_pas.c
[ ... ]
> @@ -798,6 +817,64 @@ static void qcom_pas_unassign_memory_region(struct qcom_pas *pas)
>  	}
>  }
>  
> +static int qcom_pas_setup_tmd(struct qcom_pas *pas, const struct qcom_pas_data *desc)
> +{
[ ... ]
> +	tmd_inst = qmi_tmd_init(pas->dev, desc->tmd_instance_id, tmd_names,
> +				desc->num_tmd);

[Severity: High]
Does this expose a TOCTOU race condition and state desynchronization in the
underlying QMI TMD driver?

Looking at qmi_tmd_register() in drivers/soc/qcom/qmi_tmd.c, tmd->cur_state
is read locklessly before invoking qmi_tmd_send_state_request():

drivers/soc/qcom/qmi_tmd.c:qmi_tmd_register() {
	...
	if (tmd->cdev)
		return qmi_tmd_send_state_request(tmd, tmd->cur_state);
	...
}

A concurrent call to qmi_tmd_set_cur_state() by the thermal core can execute
between this read and the QMI request, meaning the workqueue could send the
old state to the hardware and overwrite the thermal core's newly requested
state.

Additionally, when qmi_tmd_send_state_request() is called while the
connection is not active (e.g., during a remote subsystem restart), it
returns 0 without updating the state:

drivers/soc/qcom/qmi_tmd.c:qmi_tmd_send_state_request() {
	guard(mutex)(&qmi_tmd_cli->mutex);

	if (!qmi_tmd_cli->connection_active)
		return 0;
	...
}

The thermal core assumes the update was successful, but the old state is
retained. When the connection is restored, qmi_tmd_register() restores the
old state, permanently dropping the thermal core's requested state.

Can this cause the thermal core and the remote hardware mitigation state to
become permanently desynchronized?

> +	if (IS_ERR(tmd_inst)) {
> +		ret = PTR_ERR(tmd_inst);
> +		if (ret == -ENODEV)
> +			return 0;
> +
> +		return ret;
> +	}
> +
> +	pas->tmd_inst = tmd_inst;
> +
> +	return 0;
> +}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260731-b4-qmi-tmd-v7-0-3befd44403d5@oss.qualcomm.com?part=3