Linux IOMMU Development
 help / color / mirror / Atom feed
From: Robin Murphy <robin.murphy@arm.com>
To: Li RongQing <lirongqing@baidu.com>,
	joro@8bytes.org, will@kernel.org, iommu@lists.linux.dev,
	baolu.lu@linux.intel.com, vasant.hegde@amd.com
Subject: Re: [PATCH][v2] iommu: move the adding group info to proper place
Date: Tue, 11 Feb 2025 17:51:12 +0000	[thread overview]
Message-ID: <8788e433-e1c7-4a00-ac0b-fb422b9bc7b2@arm.com> (raw)
In-Reply-To: <20250107033558.41135-1-lirongqing@baidu.com>

On 2025-01-07 3:35 am, Li RongQing wrote:
> After commit fa0828036488 ("iommu: Split iommu_group_add_device()"), the
> adding group information is left in iommu_group_alloc_device, but which
> only allocate group device, not attach the device to iommu group;
> 
> so move the print to iommu probing and adding functions

But why? In what way is it justifiably better to have duplicate copies 
of the same code when the fact is that the only parts of the 
iommu_group_add_device() operation which can fail *are* the ones inside 
iommu_group_alloc_device()?

> Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com>
> Signed-off-by: Li RongQing <lirongqing@baidu.com>
> ---
> Diff with v1: add log when iommu_group_alloc_device failed in iommu_group_add_device
> 
>   drivers/iommu/iommu.c | 21 ++++++++++++++-------
>   1 file changed, 14 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> index 599030e..2eaa8ab 100644
> --- a/drivers/iommu/iommu.c
> +++ b/drivers/iommu/iommu.c
> @@ -586,6 +586,9 @@ static int __iommu_probe_device(struct device *dev, struct list_head *group_list
>   
>   	mutex_unlock(&group->mutex);
>   
> +	trace_add_device_to_group(group->id, dev);
> +	dev_info(dev, "Adding to iommu group %d\n", group->id);

If you want to argue semantics, this is now just as much in the wrong 
place as you claim the current error message to be: by this point we are 
no longer, as implied, about to add the device to the group, we've 
already finished doing that and potentially various other subsequent 
things too.

> +
>   	return 0;
>   
>   err_remove_gdev:
> @@ -594,6 +597,7 @@ static int __iommu_probe_device(struct device *dev, struct list_head *group_list
>   err_put_group:
>   	iommu_deinit_device(dev);
>   	mutex_unlock(&group->mutex);
> +	dev_err(dev, "Failed to add to iommu group %d: %d\n", group->id, ret);

This is inaccurate, because we can also get here for further error 
reasons after the device technically *was* successfully added to the 
group (in terms of the nominal iommu_group_add_device() operation within 
the wider "probe device" functionality here).

>   	iommu_group_put(group);
>   
>   	return ret;
> @@ -1192,10 +1196,6 @@ static struct group_device *iommu_group_alloc_device(struct iommu_group *group,
>   		goto err_free_name;
>   	}
>   
> -	trace_add_device_to_group(group->id, dev);
> -
> -	dev_info(dev, "Adding to iommu group %d\n", group->id);
> -
>   	return device;
>   
>   err_free_name:
> @@ -1204,7 +1204,6 @@ static struct group_device *iommu_group_alloc_device(struct iommu_group *group,
>   	sysfs_remove_link(&dev->kobj, "iommu_group");
>   err_free_device:
>   	kfree(device);
> -	dev_err(dev, "Failed to add to iommu group %d: %d\n", group->id, ret);
>   	return ERR_PTR(ret);
>   }
>   
> @@ -1219,10 +1218,14 @@ static struct group_device *iommu_group_alloc_device(struct iommu_group *group,
>   int iommu_group_add_device(struct iommu_group *group, struct device *dev)
>   {
>   	struct group_device *gdev;
> +	int ret;
>   
>   	gdev = iommu_group_alloc_device(group, dev);
> -	if (IS_ERR(gdev))
> -		return PTR_ERR(gdev);
> +	if (IS_ERR(gdev)) {
> +		ret = PTR_ERR(gdev);
> +		dev_err(dev, "Failed to add to iommu group %d: %d\n", group->id, ret);
> +		return ret;
> +	}
>   
>   	iommu_group_ref_get(group);
>   	dev->iommu_group = group;
> @@ -1230,6 +1233,10 @@ int iommu_group_add_device(struct iommu_group *group, struct device *dev)
>   	mutex_lock(&group->mutex);
>   	list_add_tail(&gdev->list, &group->devices);
>   	mutex_unlock(&group->mutex);
> +
> +	trace_add_device_to_group(group->id, dev);
> +	dev_info(dev, "Adding to iommu group %d\n", group->id);

Again, this one is now semantically wrong too.

Thanks,
Robin.

> +
>   	return 0;
>   }
>   EXPORT_SYMBOL_GPL(iommu_group_add_device);


      parent reply	other threads:[~2025-02-11 17:51 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-07  3:35 [PATCH][v2] iommu: move the adding group info to proper place Li RongQing
2025-01-07  4:00 ` Pranjal Shrivastava
2025-01-07 12:22 ` Vasant Hegde
2025-01-07 12:30   ` 答复: [外部邮件] " Li,Rongqing
2025-01-07 13:46     ` Vasant Hegde
2025-02-11 10:14 ` 答复: " Li,Rongqing
2025-02-11 17:51 ` Robin Murphy [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8788e433-e1c7-4a00-ac0b-fb422b9bc7b2@arm.com \
    --to=robin.murphy@arm.com \
    --cc=baolu.lu@linux.intel.com \
    --cc=iommu@lists.linux.dev \
    --cc=joro@8bytes.org \
    --cc=lirongqing@baidu.com \
    --cc=vasant.hegde@amd.com \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox