On Thu 30 Nov 08:46 PST 2017, Loic Pallardy wrote:
> } else {
> + /* Find any carveout matching vring */
> + /* Try dedicated vdev j vring i pool. */
> + snprintf(name, sizeof(name), "vdev%dvring%d", rvdev->index, i);
> + carveout = rproc_find_carveout_by_name(rproc, name);
This might match a carveout representing remapped device memory, which
wouldn't have a memdev so the logic below would silently allocate from
the parent dma_mem instead.
I don't think this is user friendly and would be better to just use the
information in the already mapped carveout.
> +
> + if (!carveout) {
> + /* Try dedicated vdev j vrings pool. */
> + snprintf(name, sizeof(name), "vdev%dvring", rvdev->index);
> + carveout = rproc_find_carveout_by_name(rproc, name);
> + }
> +
> + if (carveout && carveout->memdev)
> + memdev = &carveout->memdev->dev;
> +
> + rvring->dev = memdev;
> +
> /*
> * Allocate non-cacheable memory for the vring. In the future
> * this call will also configure the IOMMU for us
> */
> - va = dma_alloc_coherent(dev->parent, size, &dma, GFP_KERNEL);
> + va = dma_alloc_coherent(memdev, size, &dma, GFP_KERNEL);
It's possible that you have fulfilled a resource_table carveout request
with this memory, making the dynamic allocation likely to cause issues.
> if (!va) {
> dev_err(dev->parent, "dma_alloc_coherent failed\n");
> return -EINVAL;
Regards,
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-remoteproc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
