public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Lu Baolu <baolu.lu@linux.intel.com>
To: iommu@lists.linux.dev
Cc: Joerg Roedel <joro@8bytes.org>, Jason Gunthorpe <jgg@nvidia.com>,
	Christoph Hellwig <hch@infradead.org>,
	Kevin Tian <kevin.tian@intel.com>, Will Deacon <will@kernel.org>,
	Robin Murphy <robin.murphy@arm.com>,
	linux-kernel@vger.kernel.org, Lu Baolu <baolu.lu@linux.intel.com>
Subject: [PATCH v3 3/6] iommu: Same critical region for device release and removal
Date: Mon,  6 Mar 2023 10:58:01 +0800	[thread overview]
Message-ID: <20230306025804.13912-4-baolu.lu@linux.intel.com> (raw)
In-Reply-To: <20230306025804.13912-1-baolu.lu@linux.intel.com>

In a non-driver context, it is crucial to ensure the consistency of a
device's iommu ops. Otherwise, it may result in a situation where a
device is released but it's iommu ops are still used.

Put the ops->release_device and __iommu_group_remove_device() in a some
group->mutext critical region, so that, as long as group->mutex is held
and the device is in its group's device list, its iommu ops are always
consistent. Add check of group ownership if the released device is the
last one.

Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
---
 drivers/iommu/iommu.c | 30 ++++++++++++++++++++++++++++--
 1 file changed, 28 insertions(+), 2 deletions(-)

diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index bd9b293e07a8..0bcd9625090d 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -507,18 +507,44 @@ static void __iommu_group_release_device(struct iommu_group *group,
 
 void iommu_release_device(struct device *dev)
 {
+	struct iommu_group *group = dev->iommu_group;
+	struct group_device *device;
 	const struct iommu_ops *ops;
 
-	if (!dev->iommu)
+	if (!dev->iommu || !group)
 		return;
 
 	iommu_device_unlink(dev->iommu->iommu_dev, dev);
 
+	mutex_lock(&group->mutex);
+	device = __iommu_group_remove_device(group, dev);
+
+	/*
+	 * If the group has become empty then ownership must have been released,
+	 * and the current domain must be set back to NULL or the default
+	 * domain.
+	 */
+	if (list_empty(&group->devices))
+		WARN_ON(group->owner_cnt ||
+			group->domain != group->default_domain);
+
+	/*
+	 * release_device() must stop using any attached domain on the device.
+	 * If there are still other devices in the group they are not effected
+	 * by this callback.
+	 *
+	 * The IOMMU driver must set the device to either an identity or
+	 * blocking translation and stop using any domain pointer, as it is
+	 * going to be freed.
+	 */
 	ops = dev_iommu_ops(dev);
 	if (ops->release_device)
 		ops->release_device(dev);
+	mutex_unlock(&group->mutex);
+
+	if (device)
+		__iommu_group_release_device(group, device);
 
-	iommu_group_remove_device(dev);
 	module_put(ops->owner);
 	dev_iommu_free(dev);
 }
-- 
2.34.1


  parent reply	other threads:[~2023-03-06  2:59 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-06  2:57 [PATCH v3 0/6] iommu: Extend changing default domain to normal group Lu Baolu
2023-03-06  2:57 ` [PATCH v3 1/6] ARM/dma-mapping: Add arm_iommu_release_device() Lu Baolu
2023-03-10  1:00   ` Jason Gunthorpe
2023-03-10 22:04   ` Robin Murphy
2023-03-12  3:53     ` Baolu Lu
2023-03-06  2:58 ` [PATCH v3 2/6] iommu: Split iommu_group_remove_device() into helpers Lu Baolu
2023-03-10  1:01   ` Jason Gunthorpe
2023-03-06  2:58 ` Lu Baolu [this message]
2023-03-10  1:08   ` [PATCH v3 3/6] iommu: Same critical region for device release and removal Jason Gunthorpe
2023-03-06  2:58 ` [PATCH v3 4/6] iommu: Move lock from iommu_change_dev_def_domain() to its caller Lu Baolu
2023-03-10  1:16   ` Jason Gunthorpe
2023-03-06  2:58 ` [PATCH v3 5/6] iommu: Replace device_lock() with group->mutex Lu Baolu
2023-03-10  1:30   ` Jason Gunthorpe
2023-03-06  2:58 ` [PATCH v3 6/6] iommu: Cleanup iommu_change_dev_def_domain() Lu Baolu
2023-03-10  1:30   ` Jason Gunthorpe
2023-03-10  1:32 ` [PATCH v3 0/6] iommu: Extend changing default domain to normal group Jason Gunthorpe

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=20230306025804.13912-4-baolu.lu@linux.intel.com \
    --to=baolu.lu@linux.intel.com \
    --cc=hch@infradead.org \
    --cc=iommu@lists.linux.dev \
    --cc=jgg@nvidia.com \
    --cc=joro@8bytes.org \
    --cc=kevin.tian@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robin.murphy@arm.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