[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <653f7bf3-07b3-e411-82e1-7b4892124ef7@linux.intel.com>
Date: Tue, 15 Feb 2022 13:54:47 +0800
From: Lu Baolu <baolu.lu@...ux.intel.com>
To: Christoph Hellwig <hch@....de>
Cc: baolu.lu@...ux.intel.com, Joerg Roedel <joro@...tes.org>,
Kevin Tian <kevin.tian@...el.com>,
Ashok Raj <ashok.raj@...el.com>, Liu Yi L <yi.l.liu@...el.com>,
Jacob Pan <jacob.jun.pan@...ux.intel.com>,
Robin Murphy <robin.murphy@....com>,
Jason Gunthorpe <jgg@...dia.com>,
iommu@...ts.linux-foundation.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 10/11] iommu/vt-d: Use xarray for global
device_domain_info
Hi Christoph,
On 2/14/22 3:38 PM, Christoph Hellwig wrote:
>>
>> const struct iommu_ops intel_iommu_ops;
>> @@ -903,7 +905,8 @@ static void pgtable_walk(struct intel_iommu *iommu, unsigned long pfn, u8 bus, u
>> struct dmar_domain *domain;
>> int offset, level;
>>
>> - info = dmar_search_domain_by_dev_info(iommu->segment, bus, devfn);
>> + info = xa_load(&device_domain_array,
>> + devi_idx(iommu->segment, bus, devfn));
>> if (!info || !info->domain) {
>> pr_info("device [%02x:%02x.%d] not probed\n",
>> bus, PCI_SLOT(devfn), PCI_FUNC(devfn));
>> @@ -1742,14 +1745,14 @@ static int iommu_init_domains(struct intel_iommu *iommu)
>
> Don't we need a rcu critical section here?
>
>> - list_for_each_entry_safe(info, tmp, &device_domain_list, global) {
>> + rcu_read_lock();
>> + xa_for_each(&device_domain_array, index, info) {
>> if (info->iommu != iommu)
>> continue;
>>
>> @@ -1758,7 +1761,7 @@ static void disable_dmar_iommu(struct intel_iommu *iommu)
>>
>> __dmar_remove_one_dev_info(info);
>> }
>> - spin_unlock_irqrestore(&device_domain_lock, flags);
>> + rcu_read_unlock();
>
> __dmar_remove_one_dev_info asserts that device_domain_lock is held,
> which these two hunks remove.
>
>> spin_lock_irqsave(&device_domain_lock, flags);
>> dev_iommu_priv_set(dev, NULL);
>> - list_del(&info->global);
>> + xa_erase(&device_domain_array,
>> + devi_idx(info->segment, info->bus, info->devfn));
>> spin_unlock_irqrestore(&device_domain_lock, flags);
>>
>> kfree(info);
>
> Do we need a kfree_rcu here to allow rcu based access?
Thanks for your time and very appreciated for your comments. As replied
to Jason, I will stop 10/11 and 11/11 for now. From the current usage
scenario, the value of such refactoring is limited.
Best regards,
baolu
Powered by blists - more mailing lists