Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19;
Message-ID: <d269d0b1-2e08-d469-0e32-2b042cd79bbd@linux.intel.com>
Date:   Fri, 20 May 2022 12:55:41 +0800
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.8.1
Cc:     baolu.lu@linux.intel.com, Joerg Roedel <joro@8bytes.org>,
        Jason Gunthorpe <jgg@nvidia.com>,
        Christoph Hellwig <hch@infradead.org>,
        Kevin Tian <kevin.tian@intel.com>,
        Ashok Raj <ashok.raj@intel.com>, Will Deacon <will@kernel.org>,
        Robin Murphy <robin.murphy@arm.com>,
        Jean-Philippe Brucker <jean-philippe@linaro.com>,
        Dave Jiang <dave.jiang@intel.com>,
        Vinod Koul <vkoul@kernel.org>,
        Eric Auger <eric.auger@redhat.com>,
        Liu Yi L <yi.l.liu@intel.com>,
        Jacob jun Pan <jacob.jun.pan@intel.com>,
        iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v7 03/10] iommu/sva: Add iommu_sva_domain support
Content-Language: en-US
To:     Jean-Philippe Brucker <jean-philippe@linaro.org>
References: <20220519072047.2996983-1-baolu.lu@linux.intel.com>
 <20220519072047.2996983-4-baolu.lu@linux.intel.com> <YoZxb26tYf8mmv87@myrica>
From:   Baolu Lu <baolu.lu@linux.intel.com>
In-Reply-To: <YoZxb26tYf8mmv87@myrica>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 2022/5/20 00:33, Jean-Philippe Brucker wrote:
>> diff --git a/drivers/iommu/iommu-sva-lib.h b/drivers/iommu/iommu-sva-lib.h
>> index 8909ea1094e3..1be21e6b93ec 100644
>> --- a/drivers/iommu/iommu-sva-lib.h
>> +++ b/drivers/iommu/iommu-sva-lib.h
>> @@ -7,6 +7,7 @@
>>   
>>   #include <linux/ioasid.h>
>>   #include <linux/mm_types.h>
>> +#include <linux/iommu.h>
>>   
>>   int iommu_sva_alloc_pasid(struct mm_struct *mm, ioasid_t min, ioasid_t max);
>>   struct mm_struct *iommu_sva_find(ioasid_t pasid);
>> @@ -16,6 +17,20 @@ struct device;
>>   struct iommu_fault;
>>   struct iopf_queue;
>>   
>> +struct iommu_sva_domain {
>> +	struct iommu_domain	domain;
>> +	struct mm_struct	*mm;
>> +};
>> +
>> +#define to_sva_domain(d) container_of_safe(d, struct iommu_sva_domain, domain)
> Is there a reason to use the 'safe' version of container_of()?  Callers of
> to_sva_domain() don't check the return value before dereferencing it so
> they would break anyway if someone passes an error pointer as domain.  I
> think it matters because there is no other user of container_of_safe() in
> the kernel (the only user, lustre, went away in 2018) so someone will want
> to remove it.

Fair enough. I wondered why there's no user in the tree. Thanks for the
explanation. I will replace it with container_of().

> 
> Apart from that
> 
> Reviewed-by: Jean-Philippe Brucker<jean-philippe@linaro.org>
> 

Thank you!

Best regards,
baolu