[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20251001162516.GE3024065@nvidia.com>
Date: Wed, 1 Oct 2025 13:25:16 -0300
From: Jason Gunthorpe <jgg@...dia.com>
To: Nicolin Chen <nicolinc@...dia.com>
Cc: will@...nel.org, robin.murphy@....com, joro@...tes.org,
jean-philippe@...aro.org, miko.lenczewski@....com,
balbirs@...dia.com, peterz@...radead.org, smostafa@...gle.com,
kevin.tian@...el.com, praan@...gle.com,
linux-arm-kernel@...ts.infradead.org, iommu@...ts.linux.dev,
linux-kernel@...r.kernel.org, patches@...ts.linux.dev
Subject: Re: [PATCH rfcv2 6/8] iommu/arm-smmu-v3: Populate smmu_domain->invs
when attaching masters
On Tue, Sep 30, 2025 at 01:19:29PM -0700, Nicolin Chen wrote:
> I see a cleaner way of handling this is to update invs->num_invs
> inside arm_smmu_invs_unref():
> ----------------------------------------------------------------
> @@ -1209,6 +1216,13 @@ size_t arm_smmu_invs_unref(struct arm_smmu_invs *invs,
> j++;
> }
> }
> +
> + /* The lock is required to fence concurrent ATS operations. */
> + write_lock_irqsave(&invs->rwlock, flags);
> + /* Trim the size by removing tailing trash entries */
> + WRITE_ONCE(invs->num_invs, num_invs);
> + write_unlock_irqrestore(&invs->rwlock, flags);
That seems Ok
It means the arm_smmu_invs_unref() becomes the fence that guarentees
the ATS is stopped for anything marked as trash.
Then the next steps can just be normal RCU and don't need rwlocking.
Jason
Powered by blists - more mailing lists