linux-kernel - Re: [PATCH rfcv2 5/8] iommu/arm-smmu-v3: Pre-allocate a per-master invalidation array

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: <20250924213230.GQ2617119@nvidia.com>
Date: Wed, 24 Sep 2025 18:32:30 -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 5/8] iommu/arm-smmu-v3: Pre-allocate a per-master
 invalidation array

On Mon, Sep 08, 2025 at 04:26:59PM -0700, Nicolin Chen wrote:
> When a master is attached from an old domain to a new domain, it needs to
> build an invalidation array to delete and add the array entries from/onto
> the invalidation arrays of those two domains, passed via the to_merge and
> to_unref arguments into arm_smmu_invs_merge/unref() respectively.
> 
> Since the master->num_streams might differ across masters, a memory would
> have to be allocated when building an to_merge/to_unref array which might
> fail with -ENOMEM.
> 
> On the other hand, an attachment to arm_smmu_blocked_domain must not fail
> so it's the best to avoid any memory allocation in that path.
> 
> Pre-allocate a fixed size invalidation array for every master. This array
> will be used as a scratch to fill dynamically when building a to_merge or
> to_unref invs array.

Mention the sorting here too, though maybe that hunk should be moved
to the next patch.

> +	/* Base case has 1 ASID or 1~2 VMIDs. ATS case adds num_ids */
> +	if (!ats_supported)
> +		master->build_invs = arm_smmu_invs_alloc(2);
> +	else
> +		master->build_invs = arm_smmu_invs_alloc(2 + fwspec->num_ids);
> +	if (IS_ERR(master->build_invs)) {
> +		kfree(master->streams);
> +		return PTR_ERR(master->build_invs);
> +	}
> +
> +	/* Put the ids into order for a sorted to_merge or to_unref array */
> +	sort_nonatomic(fwspec->ids, fwspec->num_ids, sizeof(fwspec->ids[0]),
> +		       arm_smmu_ids_cmp, NULL);

The sort could be moved under the above !ats_supported, a little more
insurance in case something is inspecting the ids.

I searched around and only found tegra_dev_iommu_get_stream_id() which
is fine with the sort due to num_ids ==1

Otherwise looks OK

Reviewed-by: Jason Gunthorpe <jgg@...dia.com>

Jason