lkml.org 
[lkml]   [2022]   [Jul]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [PATCH v3 01/15] iommu/vt-d: Handle race between registration and device probe
    From
    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

    \
     
     \ /
      Last update: 2022-07-08 09:53    [W:4.125 / U:0.860 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site