Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [Critical] misc: fastrpc: fastrpc_remote_heap_map() maps unallocated CMA pages to DSP --
commit 4898c75b9b126cd912353d04edaa3233af524f7c Author: Anandu Krishnan E <[email protected]> misc: fastrpc: map ADSP remote heap into remoteproc IOMMU domain This commit detects whether the remoteproc DT node has an "iommus" property and maps the ADSP remote heap carveout into the remoteproc's IOMMU domain via iommu_map() instead of calling qcom_scm_assign_mem(). It also extracts fastrpc_remote_heap_release() to tear down the mapping or SCM assignment on driver removal and probe error paths. > diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c > index 5ac7b3e78ba7e..398bcd0cfab48 100644 > --- a/drivers/misc/fastrpc.c > +++ b/drivers/misc/fastrpc.c [ ... ] > @@ -2536,6 +2650,19 @@ static int fastrpc_init_reserved_mem(struct > fastrpc_channel_ctx *cctx, > if (domain_id == ADSP_DOMAIN_ID) { > cctx->remote_heap_addr = res.start; > cctx->remote_heap_size = resource_size(&res); > + > + rproc_node = fastrpc_get_rproc_node(rdev->of_node); > + if (rproc_node) > + cctx->use_iommu_map = of_property_present(rproc_node, > "iommus"); > + > + if (cctx->use_iommu_map) { > + err = fastrpc_remote_heap_map(rdev, rproc_node, > res.start, > + resource_size(&res)); > + of_node_put(rproc_node); > + return err; > + } [Severity: Critical] Does this map unallocated CMA pages into the ADSP IOMMU domain when the reserved-memory region is defined as a reusable shared-dma-pool? On platforms where remoteproc_adsp has an "iommus" property and adsp_rpc_remote_heap_mem is a reusable CMA pool (such as arch/arm64/boot/dts/qcom/glymur.dtsi and arch/arm64/boot/dts/qcom/talos.dtsi with talos-el2.dtso): adsp_rpc_remote_heap_mem: adsp-rpc-remote-heap { compatible = "shared-dma-pool"; alloc-ranges = <0x0 0x80000000 0x0 0x80000000>; reusable; alignment = <0x0 0x400000>; size = <0x0 0x800000>; }; During boot, rmem_cma_setup() in kernel/dma/contiguous.c initializes this region as a CMA pool, and cma_init_reserved_areas() -> cma_activate_area() releases all pageblocks in [rmem->base, rmem->base + rmem->size) into the Linux buddy allocator for movable allocations. In fastrpc_rpmsg_probe(), devm_of_reserved_mem_device_init(rdev) calls rmem_cma_device_init(), which only sets rdev->cma_area without allocating any pages from CMA. fastrpc_init_reserved_mem() then retrieves rmem->base and rmem->size via of_reserved_mem_region_to_resource(rdev->of_node, 0, &res) without calling dma_alloc_coherent() or cma_alloc() to allocate and migrate movable pages out of the CMA range. When cctx->use_iommu_map is true, fastrpc_remote_heap_map() maps [res.start, res.start + size) with IOMMU_READ | IOMMU_WRITE into the remoteproc IOMMU domain, and fastrpc_init_create_static_process() hands this range to the ADSP as its remote heap while the physical pages remain in the kernel buddy allocator and can be concurrently used by userspace processes, page cache, or fastrpc_remote_heap_alloc() buffers. (Similarly, on non-IOMMU platforms with a reusable shared-dma-pool, calling qcom_scm_assign_mem() on the unallocated range revokes HLOS permissions on pages that are still in the kernel linear map and page allocator.) Should the driver allocate the region through the DMA/CMA API before mapping or assigning it to the DSP, or should these regions not be marked reusable? -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=1
