lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ