Re: [PATCH 1/2] iommufd/device: Drop enforce_cache_coherency in iommufd_device_do_replace

[Baolu Lu]

On 2023/10/21 8:37, Nicolin Chen wrote:
> According to the conversion in the following link:
> https://lore.kernel.org/linux-iommu/20231020135501.GG3952@xxxxxxxxxx/
>
> The enforce_cache_coherency should be set/enforced in the hwpt allocation
> routine. The iommu driver in its attach_dev() op should decide whether to
> reject or not a device that doesn't match with the configuration of cache
> coherency. Drop the enforce_cache_coherency piece in replace(). Also move
> the remaining "num_devices++" piece closer to the refcount that uses this
> num_devices.
>
> Cc: stable@xxxxxxxxxxxxxxx
> Fixes: e88d4ec154a8 ("iommufd: Add iommufd_device_replace()")
> Suggested-by: Tian, Kevin <kevin.tian@xxxxxxxxx>
> Signed-off-by: Nicolin Chen <nicolinc@xxxxxxxxxx>
> ---
>   drivers/iommu/iommufd/device.c | 12 ++----------
>   1 file changed, 2 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/iommu/iommufd/device.c b/drivers/iommu/iommufd/device.c
> index e88fa73a45e6..c93f3478f808 100644
> --- a/drivers/iommu/iommufd/device.c
> +++ b/drivers/iommu/iommufd/device.c
> @@ -429,16 +429,6 @@ iommufd_device_do_replace(struct iommufd_device *idev,
>   		return NULL;
>   	}
>   
> -	/* Try to upgrade the domain we have */
> -	list_for_each_entry(cur, &igroup->device_list, group_item) {
> -		num_devices++;
> -		if (cur->enforce_cache_coherency) {
> -			rc = iommufd_hw_pagetable_enforce_cc(hwpt);
> -			if (rc)
> -				goto err_unlock;
> -		}
> -	}
> -
>   	old_hwpt = igroup->hwpt;
>   	if (hwpt->ioas != old_hwpt->ioas) {
>   		list_for_each_entry(cur, &igroup->device_list, group_item) {
> @@ -465,6 +455,8 @@ iommufd_device_do_replace(struct iommufd_device *idev,
>   
>   	igroup->hwpt = hwpt;
>   
> +	list_for_each_entry(cur, &igroup->device_list, group_item)
> +		num_devices++;

Minor: How about using list_count_nodes()?

>   	/*
>   	 * Move the refcounts held by the device_list to the new hwpt. Retain a
>   	 * refcount for this thread as the caller will free it.

Either way,

Reviewed-by: Lu Baolu <baolu.lu@xxxxxxxxxxxxxxx>

Best regards,
baolu