mirror of
https://mirrors.bfsu.edu.cn/git/linux.git
synced 2024-12-02 16:44:10 +08:00
edcc40d2ab
After binding a device to an mm, device drivers currently need to register a mm_exit handler. This function is called when the mm exits, to gracefully stop DMA targeting the address space and flush page faults to the IOMMU. This is deemed too complex for the MMU release() notifier, which may be triggered by any mmput() invocation, from about 120 callsites [1]. The upcoming SVA module has an example of such complexity: the I/O Page Fault handler would need to call mmput_async() instead of mmput() after handling an IOPF, to avoid triggering the release() notifier which would in turn drain the IOPF queue and lock up. Another concern is the DMA stop function taking too long, up to several minutes [2]. For some mmput() callers this may disturb other users. For example, if the OOM killer picks the mm bound to a device as the victim and that mm's memory is locked, if the release() takes too long, it might choose additional innocent victims to kill. To simplify the MMU release notifier, don't forward the notification to device drivers. Since they don't stop DMA on mm exit anymore, the PASID lifetime is extended: (1) The device driver calls bind(). A PASID is allocated. Here any DMA fault is handled by mm, and on error we don't print anything to dmesg. Userspace can easily trigger errors by issuing DMA on unmapped buffers. (2) exit_mmap(), for example the process took a SIGKILL. This step doesn't happen during normal operations. Remove the pgd from the PASID table, since the page tables are about to be freed. Invalidate the IOTLBs. Here the device may still perform DMA on the address space. Incoming transactions are aborted but faults aren't printed out. ATS Translation Requests return Successful Translation Completions with R=W=0. PRI Page Requests return with Invalid Request. (3) The device driver stops DMA, possibly following release of a fd, and calls unbind(). PASID table is cleared, IOTLB invalidated if necessary. The page fault queues are drained, and the PASID is freed. If DMA for that PASID is still running here, something went seriously wrong and errors should be reported. For now remove iommu_sva_ops entirely. We might need to re-introduce them at some point, for example to notify device drivers of unhandled IOPF. [1] https://lore.kernel.org/linux-iommu/20200306174239.GM31668@ziepe.ca/ [2] https://lore.kernel.org/linux-iommu/4d68da96-0ad5-b412-5987-2f7a6aa796c3@amd.com/ Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org> Acked-by: Jacob Pan <jacob.jun.pan@linux.intel.com> Acked-by: Lu Baolu <baolu.lu@linux.intel.com> Link: https://lore.kernel.org/r/20200423125329.782066-3-jean-philippe@linaro.org Signed-off-by: Joerg Roedel <jroedel@suse.de> |
||
---|---|---|
.. | ||
amd_iommu_debugfs.c | ||
amd_iommu_init.c | ||
amd_iommu_proto.h | ||
amd_iommu_quirks.c | ||
amd_iommu_types.h | ||
amd_iommu_v2.c | ||
amd_iommu.c | ||
amd_iommu.h | ||
arm-smmu-impl.c | ||
arm-smmu-qcom.c | ||
arm-smmu-v3.c | ||
arm-smmu.c | ||
arm-smmu.h | ||
dma-iommu.c | ||
dmar.c | ||
exynos-iommu.c | ||
fsl_pamu_domain.c | ||
fsl_pamu_domain.h | ||
fsl_pamu.c | ||
fsl_pamu.h | ||
hyperv-iommu.c | ||
intel_irq_remapping.c | ||
intel-iommu-debugfs.c | ||
intel-iommu.c | ||
intel-pasid.c | ||
intel-pasid.h | ||
intel-svm.c | ||
intel-trace.c | ||
io-pgtable-arm-v7s.c | ||
io-pgtable-arm.c | ||
io-pgtable.c | ||
ioasid.c | ||
iommu-debugfs.c | ||
iommu-sysfs.c | ||
iommu-traces.c | ||
iommu.c | ||
iova.c | ||
ipmmu-vmsa.c | ||
irq_remapping.c | ||
irq_remapping.h | ||
Kconfig | ||
Makefile | ||
msm_iommu_hw-8xxx.h | ||
msm_iommu.c | ||
msm_iommu.h | ||
mtk_iommu_v1.c | ||
mtk_iommu.c | ||
mtk_iommu.h | ||
of_iommu.c | ||
omap-iommu-debug.c | ||
omap-iommu.c | ||
omap-iommu.h | ||
omap-iopgtable.h | ||
qcom_iommu.c | ||
rockchip-iommu.c | ||
s390-iommu.c | ||
tegra-gart.c | ||
tegra-smmu.c | ||
virtio-iommu.c |