Messages in this thread | | | Date | Fri, 8 Jul 2022 15:52:12 +0800 | Subject | Re: [PATCH v3 01/15] iommu/vt-d: Handle race between registration and device probe | From | Baolu Lu <> |
| |
On 2022/7/6 01:08, Robin Murphy wrote: > That also highlights an issue with intel_iommu_get_resv_regions() taking > dmar_global_lock from within a section where intel_iommu_init() already > holds it, which already exists via probe_acpi_namespace_devices() when > an ANDD device is probed, but gets more obvious with the upcoming change > to iommu_device_register(). Since they are both read locks it manages > not to deadlock in practice, so I'm leaving it here for someone with > more confidence to tackle a larger rework of the locking.
I am trying to reproduce this problem. Strangely, even if I selected CONFIG_LOCKDEP=y, the kernel didn't complain anything. :-)
In fact the rmrr list in the Intel IOMMU driver is always static after parsing the ACPI/DMAR tables. There's no need to protect it with a lock. Hence we can safely remove below down/up_read().
4512 static void intel_iommu_get_resv_regions(struct device *device, 4513 struct list_head *head) 4514 { 4515 int prot = DMA_PTE_READ | DMA_PTE_WRITE; 4516 struct iommu_resv_region *reg; 4517 struct dmar_rmrr_unit *rmrr; 4518 struct device *i_dev; 4519 int i; 4520 4521 down_read(&dmar_global_lock); 4522 for_each_rmrr_units(rmrr) { 4523 for_each_active_dev_scope(rmrr->devices, rmrr->devices_cnt, 4524 i, i_dev) {
Best regards, baolu
| |