Am Montag, 9. Februar 2015, 20:19:21 schrieb Tomasz Figa: > Even though the code uses the dt_lock spin lock to serialize mapping > operation from different threads, it does not protect from IOMMU > accesses that might be already taking place and thus altering state > of the IOTLB. This means that current mapping code which first zaps > the page table and only then updates it with new mapping which is > prone to mentioned race. > > In addition, current code assumes that mappings are always > 4 MiB > (which translates to 1024 PTEs) and so they would always occupy > entire page tables. This is not true for mappings created by V4L2 > Videobuf2 DMA contig allocator. > > This patch changes the mapping code to always zap the page table > after it is updated, which avoids the aforementioned race and also > zap the last page of the mapping to make sure that stale data is > not cached from an already existing mapping. > > Signed-off-by: Tomasz Figa <[email protected]> > Reviewed-by: Daniel Kurtz <[email protected]>
I don't know enough about iommu-magic yet to review this properly, but on my rk3288-firefly the whole display pipeline stays in working condition, down to x11 and es2gears, so Tested-by: Heiko Stuebner <[email protected]> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
