[PATCH] drm/etnaviv: remove BUG_ON in MMU unmap path

Russell King - ARM Linux linux at arm.linux.org.uk
Thu Apr 28 14:37:24 UTC 2016


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.


More information about the dri-devel mailing list