linux-kernel - Re: [PATCH rfcv1 6/8] iommu/arm-smmu-v3: Populate smmu

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aLvoIp8RNQtVrjV8@nvidia.com>
Date: Sat, 6 Sep 2025 00:52:02 -0700
From: Nicolin Chen <nicolinc@...dia.com>
To: Jason Gunthorpe <jgg@...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>, <zhangzekun11@...wei.com>,
	<linux-arm-kernel@...ts.infradead.org>, <iommu@...ts.linux.dev>,
	<linux-kernel@...r.kernel.org>, <patches@...ts.linux.dev>
Subject: Re: [PATCH rfcv1 6/8] iommu/arm-smmu-v3: Populate smmu_domain->invs
 when attaching masters

On Wed, Aug 27, 2025 at 03:21:23PM -0300, Jason Gunthorpe wrote:
> On Wed, Aug 13, 2025 at 06:25:37PM -0700, Nicolin Chen wrote:
> > +static int arm_smmu_attach_prepare_invs(struct arm_smmu_attach_state *state,
> > +					struct arm_smmu_domain *new_smmu_domain)
> > +{
> 
> How about a comment:
> 
> /*
>  * During attachment the invalidation lists on the two domains are sequenced:
>  *  1. old domain is invalidating master
>  *  2. new and old domain are invalidating master
>  *  3. new domain is invalidating master
>  *
>  * This uses two updated invalidation lists, one with master added to new domain
>  * and one with master removed from old domain. Prepare these lists in advance
>  * of changing anything. arm_smmu_asid_lock ensures that the invalidation list
>  * in the domains doesn't change while we are sequencing to update it.
>  */

Having addressed the other places following your remarks, I had
a little trouble to understand that 1-2-3. But I think that can
be elaborated with:

+/*
+ * During attachment, the updates of the two domain->invs arrays are sequenced:
+ *  1. new domain updates its invs array, merging master->build_invs
+ *  2. new domain starts to include the master during its invalidation
+ *  3. master updates its STE switching from the old domain to the new domain
+ *  4. old domain still includes the master during its invalidation
+ *  5. old domain updates its invs array, unreferencing master->build_invs
+ *
+ * For 1 and 5, prepare the two updated arrays in advance, handling any changes
+ * that can possibly failure. So the actual update of either 1 or 5 won't fail.
+ * arm_smmu_asid_lock ensures that the old invs in the domains are intact while
+ * we are sequencing to update them.
+ */

Thanks
Nicolin