From: Jason Gunthorpe <jgg@nvidia.com>
To: Baolu Lu <baolu.lu@linux.intel.com>
Cc: iommu@lists.linux.dev, Joerg Roedel <joro@8bytes.org>,
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
Subject: Re: [PATCH 2/4] iommu: Use group ownership to avoid driver attachment
Date: Wed, 15 Feb 2023 08:56:33 -0400 [thread overview]
Message-ID: <Y+zWgSzwzWFjGL6m@nvidia.com> (raw)
In-Reply-To: <b7f501b0-42c4-5402-7bb1-b4681b6e624c@linux.intel.com>
On Wed, Feb 15, 2023 at 01:51:14PM +0800, Baolu Lu wrote:
> On 2/13/23 10:19 PM, Jason Gunthorpe wrote:
> > On Mon, Feb 13, 2023 at 03:49:39PM +0800, Lu Baolu wrote:
> > > The iommu_group_store_type() requires the devices in the iommu group are
> > > not bound to any device driver during the whole operation. The existing
> > > code locks the device with device_lock(dev) and use device_is_bound() to
> > > check whether any driver is bound to device.
> > >
> > > In fact, this can be achieved through the DMA ownership helpers. Replace
> > > them with iommu_group_claim/release_dma_owner() helpers.
> > >
> > > Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
> > > ---
> > > drivers/iommu/iommu.c | 27 +++++++++++++--------------
> > > 1 file changed, 13 insertions(+), 14 deletions(-)
> > >
> > > diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> > > index 4f71dcd2621b..6547cb38480c 100644
> > > --- a/drivers/iommu/iommu.c
> > > +++ b/drivers/iommu/iommu.c
> > > @@ -2807,12 +2807,6 @@ static int iommu_change_dev_def_domain(struct iommu_group *group,
> > > mutex_lock(&group->mutex);
> > > - if (group->default_domain != group->domain) {
> > > - dev_err_ratelimited(prev_dev, "Group not assigned to default domain\n");
> > > - ret = -EBUSY;
> > > - goto out;
> > > - }
> > > -
> > > /*
> > > * iommu group wasn't locked while acquiring device lock in
> > > * iommu_group_store_type(). So, make sure that the device count hasn't
> > > @@ -2971,6 +2965,7 @@ static void iommu_group_unfreeze_dev_ops(struct iommu_group *group)
> > > static ssize_t iommu_group_store_type(struct iommu_group *group,
> > > const char *buf, size_t count)
> > > {
> > > + bool group_owner_claimed = false;
> > > struct group_device *grp_dev;
> > > struct device *dev;
> > > int ret, req_type;
> > > @@ -2992,6 +2987,14 @@ static ssize_t iommu_group_store_type(struct iommu_group *group,
> > > else
> > > return -EINVAL;
> > > + if (req_type != IOMMU_DOMAIN_DMA_FQ ||
> > > + group->default_domain->type != IOMMU_DOMAIN_DMA) {
> > > + ret = iommu_group_claim_dma_owner(group, (void *)buf);
> > > + if (ret)
> > > + return ret;
> > > + group_owner_claimed = true;
> > > + }
> >
> > I don't get it, this should be done unconditionally. If we couldn't
> > take ownership then we simply can't progress.
>
> The existing code allows the user to switch the default domain from
> strict to lazy invalidation mode. The default domain is not changed,
> hence it should be seamless and transparent to the device driver.
So make that a special case, get the group lock check if it is this
case and then just adjust it and exit, otherwise get ownership under
the group lock as discussed.
>
> > which also means this needs to be
> > an externally version of iommu_group_claim_dma_owner()
>
> Sorry! What does "an externally version of
> iommu_group_claim_dma_owner()" mean?
>
Oops "externally locked"
> My understanding is that we should limit iommu_group_claim_dma_owner()
> use in the driver context. For this non-driver context, we should not
> use iommu_group_claim_dma_owner() directly, but hold the group->mutex
> and check the group->owner_cnt directly:
>
> mutex_lock(&group->mutex);
> if (group->owner_cnt) {
> ret = -EPERM;
> goto unlock_out;
> }
>
> the group->mutex should be held until everything is done.
Yes, that would be fine as long as we can hold the group mutex
throughout
Jason
next prev parent reply other threads:[~2023-02-15 12:56 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-13 7:49 [PATCH 0/4] iommu: Extend changing default domain to normal group Lu Baolu
2023-02-13 7:49 ` [PATCH 1/4] iommu: Add dev_iommu->ops_rwsem Lu Baolu
2023-02-13 14:16 ` Jason Gunthorpe
2023-02-15 5:34 ` Baolu Lu
2023-02-15 11:24 ` Robin Murphy
2023-02-16 0:40 ` Baolu Lu
2023-02-13 7:49 ` [PATCH 2/4] iommu: Use group ownership to avoid driver attachment Lu Baolu
2023-02-13 14:19 ` Jason Gunthorpe
2023-02-15 5:51 ` Baolu Lu
2023-02-15 6:56 ` Tian, Kevin
2023-02-15 7:28 ` Baolu Lu
2023-02-15 11:09 ` Robin Murphy
2023-02-16 0:42 ` Baolu Lu
2023-02-15 12:56 ` Jason Gunthorpe [this message]
2023-02-16 0:36 ` Baolu Lu
2023-02-13 7:49 ` [PATCH 3/4] iommu: Remove unnecessary device_lock() Lu Baolu
2023-02-13 7:49 ` [PATCH 4/4] iommu: Cleanup iommu_change_dev_def_domain() Lu Baolu
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=Y+zWgSzwzWFjGL6m@nvidia.com \
--to=jgg@nvidia.com \
--cc=baolu.lu@linux.intel.com \
--cc=hch@infradead.org \
--cc=iommu@lists.linux.dev \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.