Re: [PATCH RESEND v3] arm64: dts: qcom: talos: Add memory-region for audio PD

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [Critical] The fastrpc driver allocates CMA memory for the `remote_heap` and transfers ownership to the DSP via `qcom_scm_assign_mem`. However, it fails to restore ownership back to the kernel (HLOS) before freeing the memory, causing fatal kernel panics upon memory reuse.
--

commit d7ff4ea03a9a2493480fcd2856711302a7acac21
Author: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com>

arm64: dts: qcom: talos: Add memory-region for audio PD
    
Reserve memory region for audio PD dynamic loading and remote heap
requirements. Add the required VMID list for memory ownership
transfers.

> diff --git a/arch/arm64/boot/dts/qcom/talos.dtsi b/arch/arm64/boot/dts/qcom/talos.dtsi
> --- a/arch/arm64/boot/dts/qcom/talos.dtsi
> +++ b/arch/arm64/boot/dts/qcom/talos.dtsi
[ ... ]
> @@ -5195,6 +5204,9 @@ fastrpc {
>  					compatible = "qcom,fastrpc";
>  					qcom,glink-channels = "fastrpcglink-apps-dsp";
>  					label = "adsp";
> +					memory-region = <&adsp_rpc_remote_heap_mem>;
> +					qcom,vmids = <QCOM_SCM_VMID_LPASS
> +						      QCOM_SCM_VMID_ADSP_HEAP>;

[Severity: Critical]
This is a pre-existing issue, but by adding the qcom,vmids property, does
this expose a fatal kernel panic in the fastrpc driver?

Setting this property configures vmcount > 0, which triggers memory
assignment code paths in the fastrpc driver. The driver allocates CMA memory
for the remote_heap and transfers ownership to the DSP via
qcom_scm_assign_mem, but it fails to restore ownership back to the kernel
(HLOS) before freeing the memory.

For example, when a user unmaps the memory, the buffer is freed directly
back to the CMA pool:

drivers/misc/fastrpc.c:fastrpc_req_munmap_impl() {
    ...
        fastrpc_buf_free(buf);
    ...
}

The same occurs during device teardown:

drivers/misc/fastrpc.c:fastrpc_rpmsg_remove() {
    ...
    if (cctx->remote_heap)
        fastrpc_buf_free(cctx->remote_heap);
    ...
}

And the free function never reclaims HLOS ownership:

drivers/misc/fastrpc.c:fastrpc_buf_free() {
    dma_free_coherent(buf->dev, buf->size, buf->virt,
                      fastrpc_ipa_to_dma_addr(buf->fl->cctx, buf->dma_addr));
    kfree(buf);
}

Without making a qcom_scm_assign_mem hypercall to restore QCOM_SCM_VMID_HLOS
ownership before dma_free_coherent(), won't subsequent kernel accesses to
these freed pages trigger a Stage-2 permission violation and cause a
Synchronous External Abort (SEA)?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260629-talos-remoteheap-v3-1-4e23366c9196@oss.qualcomm.com?part=1