From: Jason Gunthorpe <jgg@nvidia.com>
To: Nicolin Chen <nicolinc@nvidia.com>
Cc: will@kernel.org, robin.murphy@arm.com, joro@8bytes.org,
jean-philippe@linaro.org, miko.lenczewski@arm.com,
balbirs@nvidia.com, peterz@infradead.org, smostafa@google.com,
kevin.tian@intel.com, praan@google.com, zhangzekun11@huawei.com,
linux-arm-kernel@lists.infradead.org, iommu@lists.linux.dev,
linux-kernel@vger.kernel.org, patches@lists.linux.dev
Subject: Re: [PATCH rfcv1 4/8] iommu/arm-smmu-v3: Introduce a per-domain arm_smmu_invs array
Date: Wed, 27 Aug 2025 13:48:04 -0300 [thread overview]
Message-ID: <20250827164804.GA2206304@nvidia.com> (raw)
In-Reply-To: <fbec39124b18c231d19a9b2b05551b131ac14237.1755131672.git.nicolinc@nvidia.com>
On Wed, Aug 13, 2025 at 06:25:35PM -0700, Nicolin Chen wrote:
> +/**
> + * arm_smmu_invs_del() - Remove @del_invs from @old_invs
> + * @old_invs: the old invalidation array
> + * @del_invs: an array of invlidations to delete
> + *
> + * Return: a newly allocated and sorted invalidation array on success, or an
> + * ERR_PTR.
> + *
> + * This function must be locked and serialized with arm_smmu_invs_add/dec(),
> + * but do not lockdep on any lock for KUNIT test.
> + *
> + * Caller is resposible for freeing the @old_invs and the returned one.
> + *
> + * Entries marked as trash will be completely removed in the returned array.
> + */
> +VISIBLE_IF_KUNIT
> +struct arm_smmu_invs *arm_smmu_invs_del(struct arm_smmu_invs *old_invs,
> + struct arm_smmu_invs *del_invs)
> +{
Having looked at this more completely, I think we should drop this
function.
Just always do decr, then have a simple function to compact the list
after the decr:
struct arm_smmu_invs *arm_smmu_invs_cleanup(struct arm_smmu_invs *invs,
size_t to_del)
{
struct arm_smmu_invs *new_invs;
size_t i, j;
if (WARN_ON(invs->num_invs < to_del))
return NULL;
new_invs = arm_smmu_invs_alloc(invs->num_invs - to_del);
if (IS_ERR(new_invs))
return NULL;
for (i = 0, j = 0; i != invs->num_invs; i++) {
if (!refcount_read(&invs->inv[i].users))
continue;
new_invs->inv[j] = invs->inv[i];
j++;
}
return new_invs;
}
If this returns NULL then just leave the list alone, it is OK to sit
there with the 0 users left behind.
No need for the complex _del function and the _decr function..
This also means the memory doesn't need to be preallocated and it
significantly simplifies alot of the logic.
Jason
next prev parent reply other threads:[~2025-08-27 19:15 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-14 1:25 [PATCH rfcv1 0/8] iommu/arm-smmu-v3: Introduce an RCU-protected invalidation array Nicolin Chen
2025-08-14 1:25 ` [PATCH rfcv1 1/8] iommu/arm-smmu-v3: Clear cmds->num after arm_smmu_cmdq_batch_submit Nicolin Chen
2025-08-14 1:25 ` [PATCH rfcv1 2/8] iommu/arm-smmu-v3: Explicitly set smmu_domain->stage for SVA Nicolin Chen
2025-08-14 1:25 ` [PATCH rfcv1 3/8] iommu/arm-smmu-v3: Add an inline arm_smmu_domain_free() Nicolin Chen
2025-08-14 1:25 ` [PATCH rfcv1 4/8] iommu/arm-smmu-v3: Introduce a per-domain arm_smmu_invs array Nicolin Chen
2025-08-26 19:50 ` Jason Gunthorpe
2025-08-27 0:49 ` Nicolin Chen
2025-08-27 16:48 ` Jason Gunthorpe [this message]
2025-08-27 17:19 ` Nicolin Chen
2025-08-28 12:37 ` Jason Gunthorpe
2025-08-27 20:00 ` Jason Gunthorpe
2025-09-06 8:16 ` Nicolin Chen
2025-09-08 15:51 ` Jason Gunthorpe
2025-09-08 18:20 ` Nicolin Chen
2025-08-14 1:25 ` [PATCH rfcv1 5/8] iommu/arm-smmu-v3: Pre-allocate a per-master invalidation array Nicolin Chen
2025-08-26 19:56 ` Jason Gunthorpe
2025-09-06 7:45 ` Nicolin Chen
2025-09-08 15:36 ` Jason Gunthorpe
2025-08-14 1:25 ` [PATCH rfcv1 6/8] iommu/arm-smmu-v3: Populate smmu_domain->invs when attaching masters Nicolin Chen
2025-08-27 18:21 ` Jason Gunthorpe
2025-09-06 7:52 ` Nicolin Chen
2025-09-06 8:20 ` Nicolin Chen
2025-08-14 1:25 ` [PATCH rfcv1 7/8] iommu/arm-smmu-v3: Add arm_smmu_invs based arm_smmu_domain_inv_range() Nicolin Chen
2025-08-27 18:49 ` Jason Gunthorpe
2025-09-06 8:12 ` Nicolin Chen
2025-09-08 15:39 ` Jason Gunthorpe
2025-09-08 18:19 ` Nicolin Chen
2025-09-08 18:24 ` Jason Gunthorpe
2025-09-08 18:45 ` Nicolin Chen
2025-08-14 1:25 ` [PATCH rfcv1 8/8] iommu/arm-smmu-v3: Perform per-domain invalidations using arm_smmu_invs Nicolin Chen
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=20250827164804.GA2206304@nvidia.com \
--to=jgg@nvidia.com \
--cc=balbirs@nvidia.com \
--cc=iommu@lists.linux.dev \
--cc=jean-philippe@linaro.org \
--cc=joro@8bytes.org \
--cc=kevin.tian@intel.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=miko.lenczewski@arm.com \
--cc=nicolinc@nvidia.com \
--cc=patches@lists.linux.dev \
--cc=peterz@infradead.org \
--cc=praan@google.com \
--cc=robin.murphy@arm.com \
--cc=smostafa@google.com \
--cc=will@kernel.org \
--cc=zhangzekun11@huawei.com \
/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.