linux-kernel - Re: [PATCH v2 2/2] soc: qcom: pmic_glink: Handle GLINK intent allocation rejections

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZxnrnY0rMQRWmUtd@hovoldconsulting.com>
Date: Thu, 24 Oct 2024 08:39:25 +0200
From: Johan Hovold <johan@...nel.org>
To: Bjorn Andersson <bjorn.andersson@....qualcomm.com>
Cc: Bjorn Andersson <andersson@...nel.org>,
	Mathieu Poirier <mathieu.poirier@...aro.org>,
	Chris Lew <quic_clew@...cinc.com>,
	Konrad Dybcio <konradybcio@...nel.org>,
	linux-arm-msm@...r.kernel.org,
	Bjorn Andersson <quic_bjorande@...cinc.com>,
	linux-remoteproc@...r.kernel.org, linux-kernel@...r.kernel.org,
	stable@...r.kernel.org, Johan Hovold <johan+linaro@...nel.org>
Subject: Re: [PATCH v2 2/2] soc: qcom: pmic_glink: Handle GLINK intent
 allocation rejections

On Wed, Oct 23, 2024 at 05:24:33PM +0000, Bjorn Andersson wrote:
> Some versions of the pmic_glink firmware does not allow dynamic GLINK
> intent allocations, attempting to send a message before the firmware has
> allocated its receive buffers and announced these intent allocations
> will fail.

> Retry the send until intent buffers becomes available, or an actual
> error occur.

> Reported-by: Johan Hovold <johan@...nel.org>
> Closes: https://lore.kernel.org/all/Zqet8iInnDhnxkT9@hovoldconsulting.com/#t
> Cc: stable@...r.kernel.org # rpmsg: glink: Handle rejected intent request better
> Fixes: 58ef4ece1e41 ("soc: qcom: pmic_glink: Introduce base PMIC GLINK driver")
> Tested-by: Johan Hovold <johan+linaro@...nel.org>
> Reviewed-by: Johan Hovold <johan+linaro@...nel.org>
> Signed-off-by: Bjorn Andersson <bjorn.andersson@....qualcomm.com>

Thanks for the update. Still works as intended here.

>  int pmic_glink_send(struct pmic_glink_client *client, void *data, size_t len)
>  {
>  	struct pmic_glink *pg = client->pg;
> +	bool timeout_reached = false;
> +	unsigned long start;
>  	int ret;
>  
>  	mutex_lock(&pg->state_lock);
> -	if (!pg->ept)
> +	if (!pg->ept) {
>  		ret = -ECONNRESET;
> -	else
> -		ret = rpmsg_send(pg->ept, data, len);
> +	} else {
> +		start = jiffies;
> +		for (;;) {
> +			ret = rpmsg_send(pg->ept, data, len);
> +			if (ret != -EAGAIN)
> +				break;
> +
> +			if (timeout_reached) {
> +				ret = -ETIMEDOUT;
> +				break;
> +			}
> +
> +			usleep_range(1000, 5000);

I ran some quick tests of this patch this morning (reproducing the issue
five times), and with the above delay it seems a single resend is
enough. Dropping the delay I once hit:

[    8.723479] qcom_pmic_glink pmic-glink: pmic_glink_send - resend
[    8.723877] qcom_pmic_glink pmic-glink: pmic_glink_send - resend
[    8.723921] qcom_pmic_glink pmic-glink: pmic_glink_send - resend
[    8.723951] qcom_pmic_glink pmic-glink: pmic_glink_send - resend
[    8.723981] qcom_pmic_glink pmic-glink: pmic_glink_send - resend
[    8.724010] qcom_pmic_glink pmic-glink: pmic_glink_send - resend
[    8.724046] qcom_pmic_glink pmic-glink: pmic_glink_send - resend

which seems to suggest that a one millisecond sleep is sufficient for
the currently observed issue.

It would still mean up to 5k calls if you ever try to send a too large
buffer or similar and spin here for five seconds however. Perhaps
nothing to worry about at this point, but increasing the delay or
lowering the timeout could be considered.

> +			timeout_reached = time_after(jiffies, start + PMIC_GLINK_SEND_TIMEOUT);
> +		}
> +	}
>  	mutex_unlock(&pg->state_lock);
>  
>  	return ret;

Johan