From: Nicolin Chen <nicolinc@nvidia.com>
To: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
Cc: <will@kernel.org>, <robin.murphy@arm.com>, <jgg@nvidia.com>,
<joro@8bytes.org>, <bhelgaas@google.com>, <praan@google.com>,
<kevin.tian@intel.com>, <kees@kernel.org>, <smostafa@google.com>,
<baolu.lu@linux.intel.com>,
<linux-arm-kernel@lists.infradead.org>, <iommu@lists.linux.dev>,
<linux-kernel@vger.kernel.org>, <linux-pci@vger.kernel.org>,
<skaestle@nvidia.com>, <mmarrid@nvidia.com>,
<skolothumtho@nvidia.com>, <bbiber@nvidia.com>,
<harsha.v@oss.qualcomm.com>
Subject: Re: [PATCH v3 01/13] iommu/arm-smmu-v3: Add arm_smmu_attach_release()
Date: Fri, 4 Sep 2026 13:16:30 -0700 [thread overview]
Message-ID: <apsnHhQAVPRN6AMJ@nvidia.com> (raw)
In-Reply-To: <178846311316.1308030.7431615023426150106.b4-review@b4>
Thanks for the reviews.
On Thu, Sep 03, 2026 at 12:18:33PM -0700, Jonathan Cameron wrote:
> > The IOPF teardown is done in arm_smmu_remove_master_domain() when releasing
> > the master_domain on detach, under the global arm_smmu_asid_lock mutex. But
> > the teardown must drain any in-flight IOPF (for the old domain), before the
> > master_domain is freed via iopf_queue_flush_dev() calling flush_workqueue()
> > that can block on user-faulting page-fault handlers. Doing so while holding
> > the arm_smmu_asid_lock would stall any unrelated attachment in the system.
> >
> > Split the teardown out of arm_smmu_remove_master_domain(), to a new helper
> > arm_smmu_attach_release() that runs after arm_smmu_asid_lock is released.
> >
> > Since no other device would use the old master_domain that is being freed,
> > it's safe to move out of arm_smmu_asid_lock (still under the protection of
> > iommu_group->mutex).
>
> This is a lot of text if the next bit about being a refactor only
> is accurate. Seems that not blocking attachments is the issue and
> to me that is a functional and useful change. However, is that
> in this patch? Anyhow to me this needs a rewrite to focus on just
> what is actually changing here rather than the eventual picture.
I rewrote it:
The IOPF teardown is done in arm_smmu_remove_master_domain() when releasing
the master_domain on detach, under the global arm_smmu_asid_lock mutex.
A later change will add an IOPF workqueue flush to that teardown, which can
block on a user-faulting page-fault handler. Holding the arm_smmu_asid_lock
across it would stall every unrelated attachment in the system.
Split the teardown out of arm_smmu_remove_master_domain(), to a new helper
arm_smmu_attach_release() that runs after arm_smmu_asid_lock is released.
No functional change: the old master_domain belongs to no other device, so
freeing it outside the lock stays safe, still under iommu_group->mutex.
> > +/* Release the old master_domain detached by arm_smmu_remove_master_domain() */
> > +void arm_smmu_attach_release(struct arm_smmu_attach_state *state)
> > +{
> > + struct arm_smmu_master_domain *master_domain = state->old_master_domain;
> > + struct arm_smmu_master *master = state->master;
> > +
> > + iommu_group_mutex_assert(master->dev);
> > +
> > + if (!master_domain)
>
> I guess this makes sense in later patches, but for now the local
> variable seems more confusing than anything.
I'd like to keeping this: this is prep patch anyway, so pre-adding
the local variable here can make later patches slightly cleaner.
> > + return;
>
> I'd add a blank line here to separate the sanity checks from bulk
> code.
Done.
> > arm_smmu_disable_iopf(master, master_domain);
> > kfree(master_domain);
> > + state->old_master_domain = NULL;
> > }
> >
>
> > @@ -3784,6 +3801,7 @@ int arm_smmu_set_pasid(struct arm_smmu_master *master,
> >
> This path is hit from a failure of arm_smmu_attach_prepare()
> At that point the old domain hasn't been detached.
>
> Now it doesn't matter because of what is currently done in release,
> but from a code flow / what that function is documented to be for
> this seems wrong to me. I'd separate the good and the bad
> paths in the function.
I cleaned that up -- once prepare() is done, it is in a no-fail path:
@@ -3783,8 +3784,10 @@ int arm_smmu_set_pasid(struct arm_smmu_master *master,
mutex_lock(&arm_smmu_asid_lock);
ret = arm_smmu_attach_prepare(&state, &smmu_domain->domain);
- if (ret)
- goto out_unlock;
+ if (ret) {
+ mutex_unlock(&arm_smmu_asid_lock);
+ return ret;
+ }
/*
* We don't want to obtain to the asid_lock too early, so fix up the
@@ -3798,11 +3801,9 @@ int arm_smmu_set_pasid(struct arm_smmu_master *master,
arm_smmu_update_ste(master, sid_domain, state.ats_enabled);
arm_smmu_attach_commit(&state);
-
-out_unlock:
mutex_unlock(&arm_smmu_asid_lock);
arm_smmu_attach_release(&state);
- return ret;
+ return 0;
}
static int arm_smmu_blocking_set_dev_pasid(struct iommu_domain *new_domain,
Thanks
Nicolin
next prev parent reply other threads:[~2026-09-04 20:17 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-01 0:33 [PATCH v3 00/13] iommu/arm-smmu-v3: Add PRI support Nicolin Chen
2026-09-01 0:33 ` [PATCH v3 01/13] iommu/arm-smmu-v3: Add arm_smmu_attach_release() Nicolin Chen
2026-09-01 0:46 ` sashiko-bot
2026-09-03 19:18 ` Jonathan Cameron
2026-09-04 20:16 ` Nicolin Chen [this message]
2026-09-01 0:33 ` [PATCH v3 02/13] iommu/arm-smmu-v3: Add Q_POS() macro Nicolin Chen
2026-09-01 0:38 ` sashiko-bot
2026-09-01 0:33 ` [PATCH v3 03/13] iommu/arm-smmu-v3: Drain in-flight fault events on domain detach Nicolin Chen
2026-09-01 0:48 ` sashiko-bot
2026-09-03 19:18 ` Jonathan Cameron
2026-09-04 14:09 ` Jason Gunthorpe
2026-09-04 22:57 ` Nicolin Chen
2026-09-04 21:42 ` Nicolin Chen
2026-09-01 0:33 ` [PATCH v3 04/13] iommu/arm-smmu-v3: Flush in-flight fault work " Nicolin Chen
2026-09-01 0:55 ` sashiko-bot
2026-09-03 19:18 ` Jonathan Cameron
2026-09-05 0:54 ` Nicolin Chen
2026-09-01 0:33 ` [PATCH v3 05/13] iommu/arm-smmu-v3: Allocate IOPF queue without FEAT_SVA Nicolin Chen
2026-09-01 0:46 ` sashiko-bot
2026-09-03 19:18 ` Jonathan Cameron
2026-09-01 0:33 ` [PATCH v3 06/13] iommu/arm-smmu-v3: Submit CMDQ_OP_PRI_RESP for IOPF event Nicolin Chen
2026-09-01 0:53 ` sashiko-bot
2026-09-03 19:18 ` Jonathan Cameron
2026-09-05 1:15 ` Nicolin Chen
2026-09-01 0:33 ` [PATCH v3 07/13] iommu/arm-smmu-v3: Disable the queue IRQs before disabling the SMMU Nicolin Chen
2026-09-01 0:55 ` sashiko-bot
2026-09-03 19:18 ` Jonathan Cameron
2026-09-05 3:24 ` Nicolin Chen
2026-09-01 0:33 ` [PATCH v3 08/13] iommu/arm-smmu-v3: Disable PRI when no IRQ handler is registered Nicolin Chen
2026-09-01 0:47 ` sashiko-bot
2026-09-03 19:18 ` Jonathan Cameron
2026-09-04 14:15 ` Jason Gunthorpe
2026-09-01 0:33 ` [PATCH v3 09/13] iommu/arm-smmu-v3: Support PRI Page Request in arm_smmu_handle_ppr() Nicolin Chen
2026-09-01 0:50 ` sashiko-bot
2026-09-03 19:18 ` Jonathan Cameron
2026-09-05 5:08 ` Nicolin Chen
2026-09-01 0:33 ` [PATCH v3 10/13] iommu/arm-smmu-v3: Allocate IOPF queue for ARM_SMMU_FEAT_PRI Nicolin Chen
2026-09-01 0:43 ` sashiko-bot
2026-09-03 19:18 ` Jonathan Cameron
2026-09-01 0:33 ` [PATCH v3 11/13] PCI/ATS: Add PRI stubs Nicolin Chen
2026-09-01 0:42 ` sashiko-bot
2026-09-03 19:18 ` Jonathan Cameron
2026-09-01 0:33 ` [PATCH v3 12/13] PCI/ATS: Export pci_enable_pri() and pci_reset_pri() Nicolin Chen
2026-09-01 0:44 ` sashiko-bot
2026-09-03 19:18 ` Jonathan Cameron
2026-09-01 0:33 ` [PATCH v3 13/13] iommu/arm-smmu-v3: Enable PRI for PCI device in arm_smmu_probe_device() Nicolin Chen
2026-09-01 0:51 ` sashiko-bot
2026-09-03 19:18 ` Jonathan Cameron
2026-09-05 5:53 ` Nicolin Chen
2026-09-03 19:18 ` [PATCH v3 00/13] iommu/arm-smmu-v3: Add PRI support Jonathan Cameron
2026-09-04 14:10 ` 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=apsnHhQAVPRN6AMJ@nvidia.com \
--to=nicolinc@nvidia.com \
--cc=baolu.lu@linux.intel.com \
--cc=bbiber@nvidia.com \
--cc=bhelgaas@google.com \
--cc=harsha.v@oss.qualcomm.com \
--cc=iommu@lists.linux.dev \
--cc=jgg@nvidia.com \
--cc=jonathan.cameron@oss.qualcomm.com \
--cc=joro@8bytes.org \
--cc=kees@kernel.org \
--cc=kevin.tian@intel.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=mmarrid@nvidia.com \
--cc=praan@google.com \
--cc=robin.murphy@arm.com \
--cc=skaestle@nvidia.com \
--cc=skolothumtho@nvidia.com \
--cc=smostafa@google.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