On Thu, Apr 28, 2016 at 04:04:58PM +0200, Lucas Stach wrote:
> The observation was that the common code in iommu_map() rightfully
> rejected to map things, as mapping something unaligned to the page size
> is totally bogus.
Shouldn't iommu_map() detect this?
/*
* both the virtual address and the physical one, as well as
* the size of the mapping, must be aligned (at least) to the
* size of the smallest page supported by the hardware
*/
if (!IS_ALIGNED(iova | paddr | size, min_pagesz)) {
pr_err("unaligned: iova 0x%lx pa %pa size 0x%zx min_pagesz 0x%x\n",
iova, &paddr, size, min_pagesz);
return -EINVAL;
}
where min_pagesz is derived from:
.pgsize_bitmap = SZ_4K,
and will be 4096. So, iommu_map() should reject this, and
etnaviv_iommu_map() will tear down the partially created mapping, and
propagate the error code to its caller, that being etnaviv_iommu_map_gem().
etnaviv_iommu_map_gem() will remove the drm_mm node, propagating the
failure up to etnaviv_gem_mapping_get(), which will free the
etnaviv_vram_mapping structure.
I fail to see how we could get into etnaviv_iommu_unmap() with a bad
mapping, other than if there's memory corruption, and if there is
memory corruption, hanging the kernel with a BUG_ON() is totally the
right thing to do. Better that than a corrupted filesystem.
--
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
